From: garoth@gmail.com (Andrei Thorp)
Subject: [sup-talk] On making kill-thread easier
Date: Thu, 20 Aug 2009 14:19:19 -0400 [thread overview]
Message-ID: <1250792255-sup-4740@Longbow> (raw)
In-Reply-To: <1250785604-sup-5488@yoom.home.cworth.org>
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)
next prev parent reply other threads:[~2009-08-20 18:19 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-08-20 17:07 Carl Worth
2009-08-20 18:19 ` Andrei Thorp [this message]
2009-08-20 20:01 ` Chris Wilson
2009-08-20 20:36 ` Andrei Thorp
2009-08-20 21:07 ` Carl Worth
2009-08-20 20:43 ` Ben Walton
2009-08-20 21:11 ` Carl Worth
2009-08-20 22:56 ` Ben Walton
2009-08-21 0:09 ` Carl Worth
2009-08-21 1:36 ` Carl Worth
2009-08-21 15:16 ` Chris Wilson
2009-08-21 15:19 ` Edward Z. Yang
2009-08-21 15:20 ` Ben Walton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1250792255-sup-4740@Longbow \
--to=garoth@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox