From mboxrd@z Thu Jan  1 00:00:00 1970
From: garoth@gmail.com (Andrei Thorp)
Date: Tue, 18 Aug 2009 18:07:28 -0400
Subject: [sup-talk] What's your sup workflow (and a spew of ideas)
In-Reply-To: <1250629282-sup-8521@yoom>
References: <1250629282-sup-8521@yoom>
Message-ID: <1250632714-sup-9910@Longbow>

Excerpts from Carl Worth's message of Tue Aug 18 17:02:05 -0400 2009:
> * [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?

Yeah, I'd really really like this also. This has been discussed, and in
general, it'd be lovely to be able to sort by hook or something. I think
grouping by labels first and then by time would be a good default.

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

I assume here that part of the problem is the time it takes to write
changes. If I read all my morning e-mails and then press $, it usually
takes a few seconds for this to finish. If it's just one e-mail, there
is still usually a noticeable-ish delay.

However, perhaps Xapian will improve this speed also, and if this is the
case, I'd love an "autosave" option at least in the config.
> * [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.

I think I agree there, and vaguely recall someone attempting to
implement being able to switch buffers even when an external editor is
in effect.

Anyway, impressive post there. You seem to really abuse your e-mail
client and know what you're on about. Good stuff.
-- 
Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com)