DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:sender:in-reply-to:references:date
	:x-google-sender-auth:message-id:subject:from:to:cc:content-type;
	b=UJKNZ4lIpbs/ZjWyDWr1O2Lm8kA2mTgkQcPM1mrm50aCJ5Rs8V9FS1mIKP9vG0329y
	BlrnO5PkxqTI1ryrXLMuKRfoArEoJJjWxzwRZHnJIuHPXWve/MwDxNlWpaMuoQKC6ami
	IRmK6yms6PIBarNJl4Mi9j0yOLs6xR+mh5Sy8=
MIME-Version: 1.0
Sender: amdragon@gmail.com
In-Reply-To: <1308843366-6159-1-git-send-email-l.rilling@av7.net>
References: <1308843366-6159-1-git-send-email-l.rilling@av7.net>
Date: Fri, 24 Jun 2011 11:19:34 -0400
Message-ID: <BANLkTin7R2oRu_1DSjzHSVupELru8R_tZQ@mail.gmail.com>
Subject: Re: [RFC][PATCH] tags_to_maildir_flags: Add option to not move
	messages from "new/" to "cur/"
From: Austin Clements <amdragon@mit.edu>
To: Louis Rilling <l.rilling@av7.net>
Content-Type: text/plain; charset=ISO-8859-1
Cc: notmuch@notmuchmail.org
Precedence: list

Welcome to notmuch!

>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).

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).

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.

[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