From mboxrd@z Thu Jan  1 00:00:00 1970
From: garoth@gmail.com (Andrei Thorp)
Date: Thu, 20 Aug 2009 14:19:19 -0400
Subject: [sup-talk] On making kill-thread easier
In-Reply-To: <1250785604-sup-5488@yoom.home.cworth.org>
References: <1250785604-sup-5488@yoom.home.cworth.org>
Message-ID: <1250792255-sup-4740@Longbow>

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)