On Mon, 25 Jan 2010 14:49:00 +0100, "Sebastian Spaeth" <sebast...@sspaeth.de> wrote: > > On Mon, 25 Jan 2010 13:46:59 +1300, martin f krafft <madd...@madduck.net> > wrote: > > I think we all kinda agreed that the Maildir flags should not be > > used by notmuch and that things like Sebastian's notmuchsync should > > be used if people wanted flags represented in Maildir filenames. > > While notmuchsync fullfils my needs, it is a kludge. It needs to call > "notmuch" for each mail where a MailDir flag has changed (which can be > quite often on an initial run, where most mails are likely to be read), > this can take a long, long time. It would makes sense IMHO to at least > pick pioto's "don't set unread if 'S' flag is set" on notmuch new.
notmuchsync, as currently implemented, suffers from major performance issues, in my opinion. It's a useful short term workaround, but not a good long term solution. But, I personally will always be using both notmuch and some other IMAP client (my phone). I want the two to remain in sync easily enough. notmuch is already much more robust with respect to that than sup, I think (in terms of handling renames without barfing, etc). At the very least, I want `notmuch new` to be able to: If it sees a rename that involves changing maildir flags, alter the related tags as necessary. Similarly, provide a mechanism for correlating the folder name with some set of tags, and change those tags as messages are moved around. For example, I might have: ~/.notmuch-config: [database] path=/home/pioto/mail ... [tags] pi...@pioto.org/INBOX.ListMail.notmuch = notmuch So, a 'tags' section, where each key is the folder name, relative to the db path, and the value is one or more tag names This means that I could relabel a message in gmail, for example, and have the changes apply to notmuch at my next offlineimap run. And, it means that my existing procmail rules will still be useful both to notmuch, and to my phone, for the purpose of categorizing things. I agree that all this should be optional. But, since it is likely the behavior most people would expect, I think it should be the default. PS. You mean the 'new-unread' branch, not the 'noarg-count' branch, from my repo. -- Mike Kelly _______________________________________________ notmuch mailing list firstname.lastname@example.org http://notmuchmail.org/mailman/listinfo/notmuch