On 24/06/11 11:19 -0400, Austin Clements wrote:
> Welcome to notmuch!

Thanks!

> 
> From your description, I assume you're using both notmuch and another
> MUA simultaneously.  I'm betting that MUA is mutt (though please
> correct me if I'm wrong).

Correct :)

> 
> Unfortunately, mutt's interpretation of maildir doesn't agree with the
> rest of the world.  I don't know of any other MUA that exposes the
> distinction between mail in the "new" directory and mail in the "old"
> directory (at least Dovecot, Evolution, Gnus, Kmail, and of course
> notmuch don't).  In other MUA's, any mail in the "new" directory is
> immediately moved to "cur" and "new" mail is simply anything without
> the seen flag.  mutt, on the other hand, only considers mail in the
> "new" directory to be "new".
> 
> While the maildir specification is a little vague, it strongly implies
> two things that mutt's approach violates: mail should never move from
> "cur" to "new", and only mail in "cur" can have flags [1].  While it
> never states it outright, the philosophy is that "new" is simply a
> staging ground for incoming mail, not a user-visible state (and
> certainly not user-manipulable).

Thanks for the detailed explanation.

> 
> Because of this, I don't think notmuch is the right place to change
> this (certainly not in a way that would also violate the spec).  Could
> you elaborate a bit on your workflow?  (In particular, are you using
> mutt's distinction between new and old?)  Maybe we can find an
> alternate solution.

Yes my quick "mood-dependent" filtering just acts on new (as shown by mutt)
mails, while old mails are kept until either 1) they can be read (yes, this
happens!), or 2) they can be archived (because they might be interesting in
some future), or 3) they can be deleted (eg. became too old to be worth
reading them).

However, I don't think that I need the violating behavior of mutt: new mails
are just new, not replied to/read, or anything else. The only rare cases in
which I may set back the new flag are when I mistakenly start reading an email
(wrong keystroke most of the time). Even in that case, I don't care if the mail
becomes old (ie moves to cur/).

Maybe the alternate solution could consist in simply not renaming emails having
no flags to be changed (Currently notmuch_message_tags_to_maildir_flags()
unconditionally moves messages from new/ to cur/). This would even lead to a
shorter patch :) Do you think that this would be acceptable?

Thanks,

Louis

> 
> [1] There's a bug open about the second problem (thanks to ccxCZ for
> finding this):
>     http://dev.mutt.org/trac/ticket/2476
> Of course, fixing that implies addressing the first problem, too.
> 
> On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling <l.rilling@av7.net> wrote:
> > notmuch_message_tags_to_maildir_flags() moves messages from maildir directory
> > "new/" to maildir directory "cur/", which makes messages lose their "new" status
> > in the MUA. However some users want to keep this "new" status after, for
> > instance, an auto-tagging of new messages.
> >
> > This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), which
> > does the same job as notmuch_message_tags_to_maildir_flags() except moving
> > from "maildir "new/" to maildir "cur/". A new option "preserve_new" is
> > introduced in "[maildir]" section of .notmuch-config, so that users can
> > configure whether commands "notmuch tag" and "notmuch restore" preserve the
> > "new" status or not.
> >
> > Signed-off-by: Louis Rilling <l.rilling@av7.net>
> > ---
> > Hi,
> >
> > I'm in the process of using notmuch, but the issue "addressed" by this patch
> > would make me change my habits a bit too fast. I use the "new" status for
> > quickly checking (often without reading) which emails I just received,
> > implementing some kind of context/mood/daytime-dependent quick filtering. I'd
> > also like to run a pre-tagging script automatically when synchronizing
> > periodically (and automatically too) my mailboxes. But the current behavior of
> > "notmuch tag" makes me lose my quick filtering ability.
> >
> > This patch is mostly written for discussion. It is certainly not polished (API,
> > ABI, bindings) and not tested at all. In particular, I know that there are some
> > plans to customize flags synchronization, but I don't know how the library API
> > could/should be impacted.
> >
> > Thanks for your comments!
> >
> > Louis