[neomutt-devel] [neomutt/neomutt] Add support to IMAP custom keywords (#399)
z+mutt+neomutt at m0g.net
Fri Feb 17 17:37:28 CET 2017
On Fri, Feb 17, 2017 at 03:46:08PM +0000, Pietro Cerutti wrote:
> > All in all keywords and labels are meant to be both human readable and
> > machine readable, because in the end they're used directly or indirectly
> > bu an user to lookup and/or group e-mails.
> I don't agree with the first part of this sentence. IMAP Flags are meant
> to be machine readable and understandable. I still have to see a client
> that displays them as they are and allow modification in a free-form
> textbox. Again, they are *used* by client application to store specific
> On the other hand, I don't think any client does anything particular
> with Keywords, other than displaying them as-is and allow to change
Well, I think it's up to the user to choose how they want to use the
tool. If you think it's a client-only thing like Pietro, you should be
able to configure the MUA to only read IMAP keywords, but not write to
If you think, like David, it's better to keep X-Label and IMAP synced,
then it should be possible, and the X-Label syntax shall be restricted
to the charset IMAP allows.
If like me, you're a heavy notmuch user, you'll want to avoid mutating
the mails, so you don't break notmuch's index. That means, no X-Label.
At the end of the day, David is right:
• IMAP keywords are labels.
• X-Label (Keywords/X-Keywords) are labels.
• Notmuch tags are labels.
What all that means is that we're all using the same tool with a
different toolset, but that does not mean we cannot implement a common
API that can handle all the backends. I think those should be
implemented in a way that offers enough flexibility so that an user can
• X-Labels mirror IMAP keywords, or not ;
• have IMAP keywords be interpreted as a special UI thing
• X-Labels and notmuch keywords work together without impacting the other
I believe all the scenarios we're discussing can be done using an
homogeneous CRUD+search API that exposes the different backends.
That API would be:
• add/remove/modify tags
• show tags as expandos for the index
• show tags as a fake header for the pager
• have a filter value for filtering results based on tags
• have a command to create a vfolder using a search based on tags
• have a command to sync the index with the mailbox (for external
backends like notmuch)
Then we could consider options to handle backends:
• an option to mirror X-Labels with a context-bound index (imap, notmuch, ???)
• an option to select the backend(s) we want for the API, so that we can
work with all, or only on one. (that option could be split for reads and
Then that API could be implemented with a strategy pattern (aka a struct
of function pointers) for all the backends, in a similar way we've got
for the hcache or the mailboxes.
Making it OK that some backends just return an error when an API
function implementation does not makes sense for a given pattern, or
just ignore a feature when not possible (notmuch tag update on an imap
server, or labels-sync on x-labels).
I might be forgetting some use cases here, so it's open for comments. I
guess David might need some convincing to accept the idea of fake header
and vfolders. And how to show off tags in the fake header is also
subject to discussion, but that's implementation details that are a good
thing to discuss.
What do you think of the above?
David, where can we find the updates you're thinking for next release
(including your own take at IMAP keywords)?
I'd be happy to see notmuch not a special case anymore, and labels
indexing support just another mutt handles nicely (like mailbox, hcache
or crypto backends).
More information about the neomutt-devel