Excerpts from Carl Worth's message of Thu Aug 20 13:07:16 -0400 2009: > 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).
Seems like making it the default is a bit cavalier. It's not good to assume what the user wants, I think. Maybe a separate key if we want to spare it, but I think the better solution is "learn to kill threads already and use an explicit command for it." -- Andrei Thorp, Developer: Xandros Corp. (http://www.xandros.com) _______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
