From: Michal Sojka <sojkam1@fel.cvut.cz>
To: Carl Worth <cworth@cworth.org>, Dirk Hohndel <hohndel@infradead.org>,
	Matt Fleming <matt@console-pimps.org>, notmuch@notmuchmail.org
Subject: Re: [PATCH 0/4] Maildir synchronization
In-Reply-To: <87sjzopmga.fsf@yoom.home.cworth.org>
References: <1273580061-22580-1-git-send-email-sojkam1@fel.cvut.cz>
	<87d3w082dh.fsf@linux-g6p1.site> <m3zkz3d210.fsf@x201s.gr8dns.org>
	<87typbzdnt.fsf@steelpick.2x.cz>
	<87sjzopmga.fsf@yoom.home.cworth.org>
User-Agent: Notmuch/0.3.1-113-g782e2e3 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Sat, 30 Oct 2010 14:13:50 +0200
Message-ID: <87tyk3vpxd.fsf@wsheee.2x.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Precedence: list

On Sat, 30 Oct 2010, Carl Worth wrote:
> On Thu, 10 Jun 2010 06:59:02 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:
> > This is a known limitation.
> > From id:1273580061-22580-3-git-send-email-sojkam1@fel.cvut.cz:
> > 
> >    The reason is that when you view the message its unread tag is
> >    removed which leads to rename of the file, but Emacs still uses the
> >    original name to access the attachment.
> > 
> >    Workaround: close the message and open it again.
> 
> These patches do indeed look very interesting. But the above limitation
> is really too severe. It just breaks things to much. Let's get that
> fixed first.
> 
> > IMHO, the final solution to this issue would be the "notmuch cat"
> > command. With this command, emacs would not access the messages by file
> > name, but by message id.
> 
> Sounds like a great idea. Instead of "notmuch cat", how about we name
> this "notmuch show --format=raw"? That should be even easier to
> implement, too.

See id:1287739684-26188-1-git-send-email-sojkam1@fel.cvut.cz for my last
attempt to implement this. I didn't implement it as --format=raw because
it seems that notmuch show always constructs threads even if they are
not used. I didn't check the code carefully so I may be wrong. Let me
know if you really prefer raw format over cat.

> Finally, as for configuration, I don't like the numeric codes for this
> feature. Do we really need that much granularity in the functionality
> here? Other mail clients certainly don't. From what I can see, most mail
> clients just twiddle these flags unconditionally.
> 
> I can imagine some people might want to be able to turn the feature off
> entirely, so maybe we'll need that.>

I agree that having only on/off settings should be sufficient for most
users. I'll send updated patches in a while.
 
> Or perhaps more importantly than configuration, we need the ability to
> easily migrate people to a synchronized state. For example, in my
> current mail store, most filenames have never been changed, so I've got
> a lot of files with flags that don't match my tags. What do you think
> would be the best way to resolve a situation like that?

One thing is that if you simply enable maildir synchronization and run
notmuch new, it should not touch your tags as the tags are modified only
when a new or renamed message is found. So if one doesn't modify the
flags by other programs it is safe to enable maildir synchronization.

Then, if other programs that may modify the flags are used, the mail
store flags should be made synchronized. One way of doing this manually
is to execute the following sequence of commands after enabling maildir
synchronization.

notmuch dump > x    # stores the tags
notmuch new         # makes sure that the file names in the database are up to date
notmuch restore < x # sets maildir flags to match the tags

If you want this to happen automatically, it might be possible to
modify notmuch new to use something like
notmuch->xapian_db->get_metadata("maildir_in_sync") and if this metadata
is not found and the maildir synchronization is enabled then it would
synchronize the flags and set the database metadata.

-Michal