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

[Ben Gamari]

Excerpts from Jameson Rollins's message of Sat Jan 16 18:38:40 -0500 2010:
> 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.
> 
I strongly disagree. The fact that mail readers _might_ behave
differently is not a good reason to enforce this on the notmuch layer.
In fact, it might be that mail readers purposefully want to handle
'inbox' and 'unread' differently. If that is what they want to do, then
they should be able to. Even if tagging conventions do differ, it would
be trivial to write a script to make the transition. This is because of
notmuch's simplicity and flexibility and why it is important to keep it
that way by avoiding adding unnecessary (even redundant) logic as you
propose below.

> 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 at finestructure.net.
> 
I fail to see how this offers anything not provided by Carl's original
proposal. As far as I can see, it adds more code to notmuch while
providing no functionality not already attainable and while potentially
placing limits on what is possible.

In my opinion, notmuch should provide little more than a mail store.
There are much better places to put this sort of policy than in notmuch.

- Ben