From: "Sebastian Spaeth" <Sebastian@SSpaeth.de>
To: notmuch@notmuchmail.org
In-Reply-To: <20100119152427.GL8342@finestructure.net>
References: <87pr57jvkz.fsf@SSpaeth.de>
	<201001181641.25647.sojkam1@fel.cvut.cz> <87hbqjwgmf.fsf@SSpaeth.de>
	<87my0a5i80.fsf@SSpaeth.de> <87my0aqgw9.fsf@veldthuis.com>
	<20100119152427.GL8342@finestructure.net>
Date: Tue, 19 Jan 2010 16:52:42 +0100
Message-ID: <877hrexfat.fsf@SSpaeth.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Subject: Re: [notmuch] Introducing notmuchsync
Precedence: list

On Tue, 19 Jan 2010 10:24:27 -0500, Jameson Rollins <jrollins@finestructure.net> wrote:
> Actually, I don't think this is exactly correct.  I believe that the
> move from new to cur should be done by the MUA when the MUA actually
> processes the message, but before the user views the message.  The S
> flag should then be added by the MUA when the user actually views the
> message.  The MTA should be delivering messages to new, and the MUA
> should move it to cur.  That is at least how's it's described by DJB
> for qmail (see THE MAILDIR STRUCTURE section in the qmail man page):

I have done it now as suggested by Marten: move the mail to "cur" when the
user has actually seen it (as per lack of the 'unread' tag). While I
agree that it probably should move it earlier (when it is "processed"
whatever that means for notmuch), this was just the most convenient for
me. In addition, I have also not found a maildir specification, so the
behavior seems to be a bit undefined.

> Currently notmuch itself does not really conform to what I believe is
> the maildir spec, which makes it a little difficult to use with other
> MUAs.  Notmuch does not move messages from new to cur, or modify the
> flags.  

That is why I have coded my notmuchsync tool. It does all that. While I
agree that notmuch should probably (and faster) do all that itself, the
current design seems to be to keep notmuch flexible, small and to never touch
your mailstore. Until that changes, surrounding scripts will have to
perform these tasks.

My current synchronization script looks basically like this:

notmuch new       # make db consistent (earlier deleted mails etc)
notmuchsync -s -n # MailDir flags update and "cur" dir moving
offlineimap       # sync with IMAP server
notmuch new       # incorporate new mails in notmuch db

spaetz