[sup-talk] What's your sup workflow (and a spew of ideas)

Carl Worth cworth at cworth.org
Tue Aug 18 17:02:05 EDT 2009

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

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.

* [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.)

* [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

  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

* [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).

* [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).

* [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

  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.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090818/43f15a25/attachment.bin>

More information about the sup-talk mailing list