From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] On making kill-thread easier
Date: Thu, 20 Aug 2009 17:09:30 -0700 [thread overview]
Message-ID: <1250812689-sup-2614@yoom.home.cworth.org> (raw)
In-Reply-To: <1250808931-sup-3198@ntdws12.chass.utoronto.ca>
Excerpts from Ben Walton's message of Thu Aug 20 15:56:52 -0700 2009:
> My own personal habits are such that an archived thread has to really
> bug me before I kill it, so much of the first (morning) pass is for
> 'A.' Part of this is because while I don't want to necessarily follow
> a thread, there is potential for interesting things to pop in late in
> the game (many of these are on the git ml)...so, after I see a lot of
> activity on it, I may scan the thread or possibly read it.
Thanks. Those are good points. I've definitely seen some interesting
stuff on the git mailing list where threads start off looking
worthless, but then Linus comes in with some gem of insight and things
take off again.
See Joey's post on thread patterns for some examples here:
http://joey.kitenet.net/blog/entry/thread_patterns/
> Bike shedding gets killed quickly! :)
Yes! Bike shedding without kill-thread available is a lot more painful.
I guess part of what I'm getting at with the idea of merging "archive"
and "kill-thread" is that I think the distinction between these two
commands forces the user to get a little too chummy with details of
the mail store.
I wrote a long post about sup and mail in general here:
http://cworth.org/sup/a-mail-client-for-geeks/ [*]
and one of the ideas I start talking about there is that I'd like my
mail client to present me with "Here's what you should find most
interesting right now", and I can implicitly give the system feedback
by either reading it or not. So "archive" vs. "kill" feels like manual
tuning of what would ideally be an automated process.
Of course, getting that process automated and working well is likely
an open research topic. I'd love for the system to take tags into
account, authors of messages, my history of reading (or not) posts by
given authors, etc. Obviously, sup's not going to acquire that kind of
functionality instantly, but it likely makes a good basis already for
someone who wants to explore that kind of thing.
So, ideas of mine like "sort certain tags before sorting by date", and
"merge archive and thread into a single key" I think are both just
baby steps toward the Big Idea I'd love to see someone tackle. Anyone
looking for a good M.S. thesis around here? (So much research has been
dedicated to spam, but has there been as much to sorting out the ham?
I should ask my C.S-professor-friend---he'd be up on the current state
of the literature here.)
-Carl
[*] See, I'm keeping some of my verbosity off the list at least. ;-)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090820/3ed0cc42/attachment.bin>
next prev parent reply other threads:[~2009-08-21 0:09 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
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 [this message]
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=1250812689-sup-2614@yoom.home.cworth.org \
--to=cworth@cworth.org \
/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