I wrote a long post that started out talking about workflows, but then went on into just a dump of feature requests. I'd like to get back to talking about workflows again a bit.
I find that when processing my mail in inbox-mode I do a first pass
with one of two different actions on each thread:
1. 'a' to archive the thread without reading
or:
2. <down-arrow> to leave the thread in my inbox for reading on
a later pass.
But this misses out on the killer-feature that was one of the things
that made me most interested in sup: kill-thread.
So I can currently decide to kill a thread instead of archiving it,
but this requires extra effort on my part, (deciding that I need to do
something more than just archiving it, and then using a different
key---currently with a keybinding that requires two keys).
What I find is that I end up using kill-thread much less frequently
than I should. Basically what ends up happening is that when a thread
comes up several times (and I keep just archiving it) before I finally
make the mental effort to kill it instead of just archiving it. And I
keep trying to train myself to not be afraid to use kill-thread more
frequently.
But then thought occurs to me, "Shouldn't sup just see that I'm not
ever reading this thread when it reappears?".
So I think what I actually want is a single keybinding that either
archives or kills a thread based on whether I've actually read any of
it or not. Does anybody else agree that that would be useful? Perhaps
even as the default?
I think a first pass that only does kill-thread if the entire thread
is unread will likely be enough. I can imagine a more clever version
that kills a thread even if it's partially read but no new messages
have been read since the last time this thread was labelled as
inbox. But that's perhaps more complexity than appropriate[*] and an
explicit kill-thread command will work just fine here.
-Carl
[*] By the way, my concern with complexity has nothing to do with the
state management in the code---that shouldn't be bad. It's more a
matter of making the user-interface easy to explain and understand. If
a tool violates that, then it can lose a user's trust, (which can be
quite fatal for a mail client).
signature.asc
Description: PGP signature
_______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk
