[notmuch] inbox/unread tags for new messages [was: Re: Thoughts on notmuch and Lua]

[Carl Worth]

On Sat, 16 Jan 2010 15:18:03 -0500, Jameson Rollins <jrollins at finestructure.net> wrote:
> Hey, Carl.  I would actually like to argue against replacing the
> 'inbox' and 'unread' tags with a single "new" tag.  Here's why:

Oh, well maybe I didn't make that very clear.

Personally, the only thing *I* would do with a "new" tag would be to
have my auto-tagger search for anything tagged as "new" and tag that as
"inbox" and "unread".

I definitely agree that it's important to separate these two
notions. And as you refer to below, the emacs UI makes plenty of
assumptions about these tags existing and manipulating them on behalf of
the user.

So the idea with "new" is really to just make the lower-level pieces of
notmuch, (the command-line interface and the library), to steal less of
the tag namespace. Specifically, the proposal is to reserve a single tag
("new") rather than two tags ("inbox" and "unread"). Then, it's a matter
of some higher-level layers (such as the emacs interface) to apply
special meaning to things like "inbox" and "unread".

> At first I didn't think I liked the fact that new messages were doubly
> tagged with 'inbox' and 'unread'.  But then I realized that what I was
> really not liking was the way that the emacs UI was handling those
> tags, and the more I thought about it I realized that those two tags
> are very useful and we just need to streamline how they're handled.

I agree some changes are needed.

> I think that the 'unread' tag should be tightly synced to the maildir
> 'S' flags, which indicate the read status on the maildir message files
> themselves.  This is useful for compatibility with other MUAs, and is
> one of the few generally useful tags that can be synced through IMAP.

The tight synchronization of this tag does seem useful. But I'm still
not sure what the precise plan here should be. We could change from having
the tag in the database be authoritative to instead have the character
in the filename be authoritative, but we would need answers for the
following questions:

  1. How do we deal with files that don't match maildir conventions?
     (Either not in a /cur or /new directory or not matching the
     filename convention.)

  2. How do we actually make the transition from the old scheme to the
     new? (Perhaps we do this with an increment in the database version
     number and transfer the data from the database to the filenames for
     all known files at the time of the upgrade?)

> The 'unread' tag should also not be something that the user ever
> consciously has to get rid of.  Notmuch MUAs should just get rid of it
> automatically when the user actually views the message.  The notmuch
> emacs UI is currently not handling this very well, but I think we can
> tweak that fairly easily.

I agree on all points. I've been sitting on an unfinished patch series
to implement some ideas I proposed here:

	id:877ht3hfh0.fsf at yoom.home.cworth.org

I plan to get back to finishing that soon. (I set all emacs interface
work aside for a while to do the rename support.) Some of the ideas I
outline there will make the handling of unread more sane I think. I'd be
glad to hear any further ideas.

> As for the 'inbox' tag, I think it should be kept because it has a
> very particular, well understood, and useful semantic meaning for MUAs
> that people already understand.  My mail inbox is actually what I'm
> syncing via offlineimap and I would like the 'inbox' tag to correspond
> directly to the messages that are in my actual maildir inbox.

Yes. If we change to "unread" simply being state that is controlled
entirely by the mailstore, then we would be to the point where "inbox"
is the only tag being claimed from the tag namespace by "notmuch
new". And at that point, I agree we could/should just leave it named
"inbox" rather than "new".

> This last point I think is very important because I think it
> corresponds to the way that *most* people are or need to handle their
> mail, and it's something that I think notmuch hasn't quite fully come
> to grips with yet.

I totally agree. One of the most-important reasons I had in mind when
starting notmuch was the desired to get to a point where I could
actually reason about, and explore more-improved mail flow. Everything
so far has been about getting some low-level plumbing working. I've got
a bunch of ideas for novel mail-handling techniques that will be enabled
by notmuch, and we definitely haven't scratched the surface yet. I'm
sure many readers of this list have similar (and different!) ideas and
I'm looking forward to seeing what we can come up with together.

> I'm going to follow up this message with another one that describes my
> idea for a streamlined message flow in notmuch that would utilize
> these tags better.

I'll look forward to that. Thanks again!

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20100116/9fdc1b6a/attachment.pgp>