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

[Jameson Rollins <jrollins@finestructure.net>]

[-- Attachment #1: Type: text/plain, Size: 6141 bytes --]

On Sat, Jan 16, 2010 at 02:22:09PM -0800, Carl Worth wrote:
> 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".

I personally don't really think that this is a good idea.  If this is
all left up to mail reader, and the mail readers all do something
different, then it would be very difficult to switch readers, or to
use different readers for different circumstances.  I really think
that all of this stuff should be handled uniformly by the notmuch CLI
in a very structured way.  If we make sane decisions at that level,
then things are nicely consistent.

What I would instead suggest is that there is a notmuch new hook,
handled at the notmuch program level, that would allow users to define
scripts or functions that would be applied to all new messages.  Then
users could do whatever they want to new messages.  As long as it's
done at the notmuch CLI level, instead of at the reader level, things
won't get fractured by divergent reader implementations.  This ideal
is also in line with the proposal I put forth in
id:20100116204955.GA858@finestructure.net.

> On Sat, 16 Jan 2010 15:18:03 -0500, Jameson Rollins <jrollins@finestructure.net> wrote: 
> > 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.)

I'm not sure this is the right question.  It seems to me that if
notmuch is going to be using maildir, then notmuch itself should do
everything to conform to the maildir convention, as well as assume
that anything else touching the same maildirs is doing so as well.
Notmuch should be moving files from new to cur as it processes them,
and it should be adding the S flag if a message has been seen/read.

If there are files in the maildir that don't conform, then they should
either be ignored with some sort of warning, or they should just be
added to the database with no special care at all (maybe with a
warning).

>   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?)

Is it really a scheme change that would require delicate handling?  I
would think that the change would be fairly straightforward:

- if notmuch sees that a message in the maildir has moved from new to
  cur and/or the S flag has been added then any 'unread' flags should
  be removed from the message.

- if a 'unread' tag is removed from a message, then the message S flag
  should be added.

It doesn't seem that any database changes need to be made.

> > 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@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.

I really think this should just be done in the most stupid simple way
imaginable: if you view/open a message buffer, the 'unread' tag goes
away.  That simple.  I really don't think it's worth spending any time
trying to make it more nuanced or sophisticated than that.  Users
should not ever have to think about changing this tag, and if they
really want to, they can just use the tag function.

> 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.

Yeah, I am totally on board with your vision for notmuch, Carl.  It's
a incredibly nice new way to handle mail.  You've done a great job
keeping things simple yet flexible.  I really hope we can continue in
that same vein.  I think that the proposal I put forward in my other
message will help further that goal (keep things simple and well
structured, but allow flexibility).

I have no doubt that there will be lots of very novel uses for notmuch
in the future.  I was already talking to a friend about how notmuch
should absolutely be used by mailing list handlers.  How sweet would
it be to have web interfaces to notmuch mail list archives.

jamie.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]