From mboxrd@z Thu Jan 1 00:00:00 1970 From: cworth@cworth.org (Carl Worth) Date: Tue, 18 Aug 2009 14:02:05 -0700 Subject: [sup-talk] What's your sup workflow (and a spew of ideas) Message-ID: <1250629282-sup-8521@yoom> I'm now a few days into using sup, and it's clearly helped me to be more productive at processing mail, (inbox is down to 0 from *lots* of messages), so thanks! However, I still don't feel like I'm experiencing the zen of sup yet. So I'm interested in hearing from others: What is your typical workflow with sup? That is: What different modes of task do you find yourself doing with sup? Precisely what keystrokes do you use for those tasks? Where, if anywhere, does sup get in your way rather than help? What follows is my (rather long) answer to those questions, and more or less a todo list of things I'd like to help improve in sup. My desired workflow =================== I think there's a basic two-level approach I take to processing new email. Fortunately, these two modes correspond well with sup's inbox-mode and thread-view-mode. Here's what I'd like to do: Identify "unimportant" threads (no need to read) ------------------------------------------------ This is a quick scan of the thread titles in my inbox. The goal here is to identify as quickly as possible threads that I will never need to read at all, (so that they can be immediately removed from my inbox). Ideally, I will make a decision in one or two seconds, and issue a single character command to indicate the decision. Dealing with remaining "important" threads ------------------------------------------ After having eliminated as many threads as possible during the scan of the inbox, I now switch to a mode where I'm actually looking at mail messages. The goal here is to identify whether I need to do anything, and how much time that will take. There are three possible outcomes: * No action needed * Quick action, (less than two minutes) * Longer action required (to assign to some project) (Any similarity to a method proposed by David Allen in Getting Things Done is not accidental, and he deserves credit as such.) Regardless of the three results, I will be quickly archiving the thread so that it's gone from my inbox. That will be either immediate archiving, archiving after a quick action (such as a reply), or archiving after tagging the thread with a label for the appropriate project. How sup could support my workflow better ======================================== So sup obviously fits in quite well with the above model---which is why I immediately fell in love with it. So first of all I have to again say thank you. And I apologize that I will go into more detail on the things I'd like to change in sup as opposed to the things that already work so well. This isn't a criticism of the tool, just an expression of my desire to improve it. I'll phrase the list below as feature requests. Some of these things may already exist in sup, and I just missed them. In such cases, I'll be glad to hear pointers to the things I missed. Otherwise, I plan to work on developing patches for these, and I'll be glad for any help. I'll give each feature a name in [square-brackets] for easy reference in followup messages. inbox-mode ----------- * [black-on-white-color-scheme] We've talked in another thread about adding support for a black-text-on-white-background color scheme to sup-config. Before I can write a patch for that, does somebody have an example black-on-white color scheme that works well? I've been trying to come up with one but I've been unable to find how to change some colors, specifically: + [change-color-of-thread-selector] The selector for the current thread in thread-mode appears as black-foreground-on-cyan right now. I haven't been able to find the setting to make that a more easy-to-read background color, and this is the only line in the view that isn't bold when unread, (which is not ideal since it's the only line I'm trying to read and process). + [change-color-of-tag-markers] The tag markers are yellow, which is hard to see on white. I also couldn't find the setting to change this. * [import-read-messages-as-archived-from-initial-sup-config-based-sync] When I very first started using sup, (running sup-config which setup sources and ran sup-sync) I was surprised to find my inbox with thousands of unread messages in it. Now that I'm using sup more I love that sup treats inbox and unread as separate labels, (far too many email programs fail to separate those notions). But for that initial import, I think it would have been much more useful to have only given the inbox tag to unread messages. * [sort-priority-labels-before-date] The default sorting for the inbox is reverse-chronological which is a reasonable-enough default, (and works fine for me when I keep my inbox small). But when I get behind and my inbox gets large, (say after a few days away from email), I do have some tags that I would like to be sorted to the top, regardless of date. How about support for a configurable list of "priority" tags that would provide a primary sort before the date-based sort? * [save-all-state-changes-immediately] The 'a' and 'd' commands do almost exactly what I expect, (by immediately making the current thread disappear and advancing the selector to the next thread). That's perfect for fast processing. One thing missing here is that they don't actually save this state, (requiring me to hit '$' at some point). Perhaps that safety feature was more important before undo was implemented, but now that it exists, would immediate state saving make sense? The two bad side effects I've experienced due to lack of immediate saving are: 1. Seeing confusingly inconsistent results after processing a bunch of my inbox and then doing a search based on label:unread or label:inbox (Why am I seeing all these messages again?). 2. Losing a bunch of processing state due to crashes. (The crashes have been due to the mbox-processing bug which has since been fixed, but being immune to state loss for any future crashes would be beneficial.) search-results-mode ------------------- * [provide-commands-to-refine-the-current-search] I mentioned above wanting to sort priority labels before date. Similarly, when processing a very large email I sometimes want to process related messages together, (to reduce mental context switches). So I want variants of both "\, F: Search all messages" and "L: list labels" search commands that refine the current search rather than doing a new global search. That is, the new commands would simply append new search terms to the current search rather than starting a new search. * [allow-for-inbox-mode-magic-elsewhere] Another way to reword this one would be to "eliminate any magic of inbox mode". My question is, "What makes inbox-mode different than search-results-mode and how can I get the behavior of inbox-mode in my searches?". Without commands to refine the current search as described above, I've been trying to achieve results like "inbox refined to label:foo" with a search as follows: label:inbox -label:killed label:foo This gives me the set of threads that I want, but now my standard processing commands no longer work. For example, the 'a' key still removes the inbox label, but it doesn't make the tag then disappear immediately. One approach to fix this would be that when adding the commands to refine the inbox search, the new search results would also be in inbox-mode with all necessary magic. A more general fix would be to process the current thread after any changes, (such as the addition or removal of a label), and removing it from the current search results if it no longer meets those criteria. * [fix-handling-of-kill-thread-outside-inbox] The handling of the "&: kill thread" command when applied outside of the inbox, (such as in search-results-mode), is currently very confusing. What it currently seems to do is to add the killed label and make the thread disappear from the current view. But then, running "@: Refresh view" will make it reappear, (whereupon one can make it disappear again with &, ad infinitum). The removal of the thread from the current view seems to be magic associated with the kill-thread command, (leading to inconsistent behavior). I would again suggest to instead implement the general fix described above, (always reprocessing a thread after label changes to see if it still meets the current search). That way, trying to kill a thread without -label:killed in the current search would simply add the "killed" label and the user would learn to add the necessary search terms, (or to do searches based on refining the searches of existing views to inherit this term). thread-view-mode ---------------- * [override-arrow-keys-to-jump-to-next-actionable-line] In thread-view-mode the up and down arrows currently advance a selector by one line at a time, (inherited from line-cursor-mode), all the way into message bodies. As far as I can tell, this is not a useful behavior. I propose that the down arrow key should instead advance the selector to the next line which would cause a context change for the various operations that can be performed based on the selector, (or scroll to the next page if there are no such lines on the current or next page). * [be-less-overzealous-in-moving-text-to-the-left-column] I tend to use sup in a very wide terminal, (200+ columns). And I'm glad to see that the inbox-mode takes advantage of this by showing a preview of the message body (that's a nice touch!) where many console-based clients just cut things off at 80 columns. However, in thread-view-mode, sup always pushes the current message all the way over to the left-hand column. This does mean that the "current" message is visible, but I have a tendency to read much more than the current message, (even before advancing), and subsequent messages are often scrolled such that the first several columns of text are scrolled off to the left. Meanwhile, I have acres of terminal real-estate to the right that sup isn't using. I would propose that messages only be scrolled to the left if necessary to avoid the 80th column of the message body not being visible, (assuming the terminal is at least 80 columns wide). compose-mode ------------ * [repeated-postponing-shouldnt-make-additional-drafts] I find that while composing a message I often want to go look at some other messages for reference. This is currently quite awkward with sup. It would be easier if sup could be run multiple times. It would also be easier if sup could somehow fire off an editor as an external process, while still allowing for sup to be operated. As it stands, instead, I have to save and quit from my editor, postpone the message within sup, and then later come back to edit it again, and find where I was in the editor. It's an expensive context switch with a lot of keystrokes and lost state, (such as where point was inside emacs, my kill ring, etc.). I'm currently finding myself sometimes just drafting messages in emacs sessions unrelated to sup, and then doing "M-x insert-file" once sup has launched emacs for me. (This does relate a bit to the point I made in a previous thread where I would love to find a way to keep all the mail-composition tasks very separate from sup, but not lose things like replied-to bits.) Anyway, the current misfeature I'm hitting is that if I do postpone a draft, then return to edit it more, then postpone it again, etc. eventually when I send the message I'll have several partially-composed drafts in various states that I need to go and manually clean up. It seems like most email programs avoid this problem by removing the draft as soon as its selected for editing again, and I propose that sup do the same. Anyway, I've probably run into several other little things that I didn't capture in this email, but I'll hopefully remember them later. If anyone has feedback on any of the above, (and actually read this far!), then I'll appreciate getting it. Otherwise, like I said, I hope to start trying to implement some of these ideas, and when I do, I'll of course come back with separate new threads for each. -Carl -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: