[PATCH/RFC 0/3] Maildir custom flags and notmuch tags

[Jan Pobrislo]

On Wed, 03 Feb 2016 08:03:08 -0400
David Bremner <david at tethera.net> wrote:

> I see, you're talking about this "dovecot-keywords" file I guess
> 
>   http://wiki2.dovecot.org/MailboxFormat/Maildir

Indeed.

> Some questions that spring to mind:
> 
> - This is clearly dovecot specific; I wonder what fraction of
>   our users would benefit. I suppose that's a question about any
> scheme involving maildir-flags a-z; at least those can be
> synchronized ootb by several tools.

Every such maildir extension out there that I know of was invented for
some specific application. Out of the two documented formats there are,
the dovecot-keywords file is:

1) more limited (26 tags maximum)
2) simpler to implement, especially wrt. detecting changes
3) usable out of the box with some tools, as you noted

Of course, one could go invent some another format, but in the end it'd
be application-specific too, and I don't see it succeeding without help
of mail-synchronizer authors.

> - Notmuch new currently only indexes one copy of a message, so two
> files in different maildirs (i.e. a list and inbox) would be pretty
> much a crapshoot which tags get applied. We intend to change this
> behaviour eventually, but no one is working on it currently.
> 
> - even if/when this behaviour changes, there is still the problem of
>   reconciling different tag mappings from several maildirs.

This is nothing new though, current synchronize_tags has the very same
problem. I'm not sure how much of a problem it is in practice, but it
probably should be addressed in some way.

Here possibly the best course of action would be to leave it open-ended
and provide user-definable conflict resolution hook, as I can't really
think of "one size fits all" solution.

> On the other hand, maybe not much change to the notmuch core would be
> needed to at least experiment with this, using e.g. hooks to
> notmuch-insert and notmuch-new.

I was pondering this before and would find it rather neat, but it is
bit more complicated than it might first seem. The hook needs to be
able to add arbitrary files to be watched for changes and deduce from
that which files need their tags re-read.