From mboxrd@z Thu Jan 1 00:00:00 1970 From: cworth@cworth.org (Carl Worth) Date: Thu, 20 Aug 2009 10:07:16 -0700 Subject: [sup-talk] On making kill-thread easier Message-ID: <1250785604-sup-5488@yoom.home.cworth.org> 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. 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). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: not available URL: