From: cworth@cworth.org (Carl Worth)
Subject: [sup-talk] Why inbox-mode instead of default search?
Date: Wed, 30 Sep 2009 09:12:35 -0700 [thread overview]
Message-ID: <1254326318-sup-904@yoom.home.cworth.org> (raw)
In-Reply-To: <1254323181-sup-1735@masanjin.net>
Excerpts from William Morgan's message of Wed Sep 30 08:16:35 -0700 2009:
> How does the notion of killing a thread that makes sense except in the
> context of having an special inbox mode?
The kill-thread notion can be handled in multiple ways without a
special inbox mode.
One way would be to simply not apply the inbox label to new messages
belonging to killed threads.
A better way would be to expand the search capability to something like:
Search for all threads containing messages matching <include-condition>
AND exclude all threads containing messages matching <exclude-condition>
I'd be happy to have that kind of functionality for arbitrary labels
that would function like killed for specific searches.
> The inbox is magical, because you do different things with your inbox
> than you do with non-inbox buffers: you classify threads into a) I'm
> done with this thread for now, but let me know if someone replies
> (archive); b) I'm done with this thread for now and don't let me know if
> someone replies (kill); c) I'll deal with this later (ignore).
It's definitely true that reading new mail is a different activity
than searching old mail, (note my recent patch that provides different
sort orders for these two operations).
But there are at least two problems with the current inbox mode
implemented separately from the search mode:
1. Some functionality appears in only one or the other of the modes.
Refine search is the easy-to-notice one that we've talked
about. But really, any keybindings performing distinct actions in
these two modes is just confusing. The two modes are far too
similar to have independent lists of possible actions and
bindings. This should be unified.
2. There are some things that are currently implemented as "magic" in
inbox mode that should really be made available to all searches.
Things like the archive operation making a message disappear from
the inbox. Instead, any operation making a message no longer
satisfy the current search should cause it to disappear from the
current view.
> > A patch to add this command to inbox-mode appears in the August sup-talk
> > archive. I would like to see this feature become part of the base system.
>
> I agree.
One shortcoming of that patch is that refined versions of the inbox
come up in search-results-mode, not inbox-mode. So you don't actually
get what you want yet, (such as archiving no longer works the same in
a refined inbox as it does in the raw inbox).
Or said another way, you would get exactly what you want if there was
nothing magic about inbox.
-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090930/1641d2ef/attachment.bin>
next prev parent reply other threads:[~2009-09-30 16:12 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-27 17:04 William Erik Baxter
2009-09-27 17:46 ` William Morgan
2009-09-27 18:50 ` William Erik Baxter
2009-09-30 15:16 ` William Morgan
2009-09-30 16:12 ` Carl Worth [this message]
2009-09-30 17:47 ` Rich Lane
2009-09-30 18:04 ` William Morgan
2009-09-30 19:12 ` Carl Worth
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=1254326318-sup-904@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