--- /dev/null
+Return-Path: <ccx@webprojekty.cz>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 4D7886DE0C1E\r
+ for <notmuch@notmuchmail.org>; Wed, 3 Feb 2016 06:33:04 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.646\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[AWL=-0.638,\r
+ RCVD_IN_RP_RNBL=1.284] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id Mq0-xyB3XvFM for <notmuch@notmuchmail.org>;\r
+ Wed, 3 Feb 2016 06:32:57 -0800 (PST)\r
+Received: from ccx.webprojekty.cz (156.200.broadband11.iol.cz\r
+ [90.178.200.156]) by arlo.cworth.org (Postfix) with ESMTP id AB8F46DE0B64 for\r
+ <notmuch@notmuchmail.org>; Wed, 3 Feb 2016 06:32:57 -0800 (PST)\r
+Received: from dorje.v103.te2000 (unknown [82.142.125.46])\r
+ (Authenticated sender: ccx@webprojekty.cz)\r
+ by ccx.webprojekty.cz (Postfix) with ESMTPSA id D80771176;\r
+ Wed, 3 Feb 2016 14:38:19 +0100 (CET)\r
+Date: Wed, 3 Feb 2016 15:32:50 +0100\r
+From: Jan Pobrislo <ccx@webprojekty.cz>\r
+To: David Bremner <david@tethera.net>, notmuch@notmuchmail.org\r
+Subject: Re: [PATCH/RFC 0/3] Maildir custom flags and notmuch tags\r
+Message-ID: <20160203153250.56aa0b2b@dorje.v103.te2000>\r
+In-Reply-To: <87d1se9f2b.fsf@zancas.localnet>\r
+References: <1448504191-30974-1-git-send-email-igor.contato@gmail.com>\r
+ <87mvsd7cxr.fsf@zancas.localnet>\r
+ <20160202175220.12f8a712@dorje.v103.te2000>\r
+ <87d1se9f2b.fsf@zancas.localnet>\r
+X-Mailer: Claws Mail 3.13.0 (GTK+ 2.24.28; x86_64-pc-linux-gnu)\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=US-ASCII\r
+Content-Transfer-Encoding: 7bit\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Wed, 03 Feb 2016 14:33:04 -0000\r
+\r
+On Wed, 03 Feb 2016 08:03:08 -0400\r
+David Bremner <david@tethera.net> wrote:\r
+\r
+> I see, you're talking about this "dovecot-keywords" file I guess\r
+> \r
+> http://wiki2.dovecot.org/MailboxFormat/Maildir\r
+\r
+Indeed.\r
+\r
+> Some questions that spring to mind:\r
+> \r
+> - This is clearly dovecot specific; I wonder what fraction of\r
+> our users would benefit. I suppose that's a question about any\r
+> scheme involving maildir-flags a-z; at least those can be\r
+> synchronized ootb by several tools.\r
+\r
+Every such maildir extension out there that I know of was invented for\r
+some specific application. Out of the two documented formats there are,\r
+the dovecot-keywords file is:\r
+\r
+1) more limited (26 tags maximum)\r
+2) simpler to implement, especially wrt. detecting changes\r
+3) usable out of the box with some tools, as you noted\r
+\r
+Of course, one could go invent some another format, but in the end it'd\r
+be application-specific too, and I don't see it succeeding without help\r
+of mail-synchronizer authors.\r
+\r
+> - Notmuch new currently only indexes one copy of a message, so two\r
+> files in different maildirs (i.e. a list and inbox) would be pretty\r
+> much a crapshoot which tags get applied. We intend to change this\r
+> behaviour eventually, but no one is working on it currently.\r
+> \r
+> - even if/when this behaviour changes, there is still the problem of\r
+> reconciling different tag mappings from several maildirs.\r
+\r
+This is nothing new though, current synchronize_tags has the very same\r
+problem. I'm not sure how much of a problem it is in practice, but it\r
+probably should be addressed in some way.\r
+\r
+Here possibly the best course of action would be to leave it open-ended\r
+and provide user-definable conflict resolution hook, as I can't really\r
+think of "one size fits all" solution.\r
+\r
+> On the other hand, maybe not much change to the notmuch core would be\r
+> needed to at least experiment with this, using e.g. hooks to\r
+> notmuch-insert and notmuch-new.\r
+\r
+I was pondering this before and would find it rather neat, but it is\r
+bit more complicated than it might first seem. The hook needs to be\r
+able to add arbitrary files to be watched for changes and deduce from\r
+that which files need their tags re-read.\r