[notmuch] notmuch 'index' mode.

[Carl Worth]

On Fri, 20 Nov 2009 23:35:29 -0800, Keith Packard <keithp at keithp.com> wrote:
> I posted a patch adding an 'index' mode to notmuch and though I'd
> explain my idea. Most mail systems provide a 'folder view' mode which
> displays the set of folders and a count of messages in each folder. I
> used this myself as the first sort of which messages I want to read.

I've just pushed this set of patches out now.

I like it quite a bit. Here are some thoughts:

  * The mode documentation really needs to walk the user through how to
    setup a custom set of folders.

  * It's not opening my "to-me" folder for some reason. (I thought it
    was the '-' at first, but "xorg-board" is working fine). I can debug
    this later.

  * The presentation is impressively spartan[*]. :-)

If we spruce this up a bit, I think we'll want to make this the default
view of "M-x notmuch".

Oh, and instead of just documenting how to set a variable in .emacs we
should just provide commands to add/remove folders.

> One missing piece here is that the searches don't have a
> total/unread count. Because the 'notmuch count' command is so fast
> (notmuch count the returns 532891 on my machine, and takes 0.240
> seconds), we really could count the number of messages matching a single
> tag and then *also* count the number of messages matching that tag and
> the inbox tag.

I think the number of threads matching the search is the only
interesting number actually. Otherwise, you just end up printing a bunch
of big numbers that the user doesn't need for anything.

> Another missing piece is that these should be shared with the
> notmuch-poll script, probably via the .notmuch-config file. I do like
> that I can have some entries here that aren't in my notmuch-poll script.

Yes, once we add configuration for automated tagging, we'll want to
figure out how to include those here. I'm not sure if they should just
be an initial default that the user tweaks, or if any configured rules
from that file should always be presented until the user explicitly asks
for one to be ignored (think about a "spam" tag). So that might take
some experimentation.

You're definitely right that we want to support searches other than
simply the tag names in the configuration file. For example, here's the
search I'm currently using for the "notmuch" folder (so I can process
outstanding patches in order):

	tag:notmuch and (tag:inbox or tag:todo)

Though, really, I probably wouldn't mind using a search string like that
for any of my automated tags. It's equivalent to what you were doing if
there are no "todo" tags on messages with the tag of interest, and then
as soon as there are any "todo" tags on any of those messages, then I
probably do want them in that folder.

So maybe the user configures a search template to use for each automatic
tag or so?

> It might be nice to make this hierarchical as I used to do with
> evolution's vfolder stuff -- an 'intel' folder with an 'intel/unread'
> sub-folder. That would be done with simple conjunctions of tags, but
> providing some structure on the screen might be nice.
> 
> I'm also wondering if we should elide, or at least change the appearance,
> of lines which match zero messages.

Two nice ideas.

> I'd also like to be able to get the system to display my mail in three
> panes -- one with the index, one with the current search and the last
> with the current thread. Getting those laid out on the screen correctly
> and letting you get them back to that layout easily would make notmuch
> look a lot more like other email clients, a form I've found fairly
> functional as I do not generally read mail in a linear fashion.

Yes. Emacs has pretty good support for saving and restoring an entire
window configuration, so we should be able to make this work.

And by the way, lest you be misled by the "magic space bar", I don't
read my mail very linearly either. I always filter by at least one tag
first and I want to prioritize which one. The folder mode is great for
this. It's only when I get my search results down below a particular
threshold that I decide I want to read everything linearly.

(And if I can't get a particular folder down that small, then I'll do
selective reading (with 'x', yes, I think we're agreeing on that now),
and then archive away the lot.)

Anyway, thanks for the great addition to notmuch.

-Carl

[*] A nice thing about this is it give us plenty of room to have a
paragraph or two explaining how notmuch works, what the user can expect,
what keys to use, etc.