[PATCH 1/3] new: Do not defer maildir flag synchronization during the first run

[Carl Worth]

On Tue, 25 Jan 2011 17:42:30 -0500, Austin Clements <amdragon at mit.edu> wrote:
> Wouldn't this be simpler and more general?
...
>         case NOTMUCH_STATUS_SUCCESS:
..
>             if (state->synchronize_flags == TRUE)
> -               _filename_list_add (state->message_ids_to_sync,
> -                                   notmuch_message_get_message_id (message));
> +               notmuch_message_maildir_flags_to_tags (message);

Yes, that is much simpler and should work equally well as the original
patch.

But there's perhaps a problem with both of these patches. Besides
rename, (which obviously can't happen with a new message), we also need
to take care when a message is added with multiple filenames (and with
different flags on the files).

We've got a plan for adding flags-to-tags mappings which only apply if
every file for the message has the corresponding flag. For example, this
is the semantic we want for the 'D' flag mapping to the "deleted" tag.

So we'll want to make sure these cases do the right thing. Consider two
new files with the same Message-Id both appearing in a run of "notmuch
new", one with the D flag and one without.

If the file with the D flag is seen first, and the maildir_flags_to_tags
processing happens without being deferred, then the "deleted" tag will
be applied to the message. This is different than would happen if both
messages were seen, but I think it's just fine. It's still in a state
that's consistent, nothing bad would happen if you interrupted this and
then acted on the "deleted" tag, and if you restarted "notmuch new" and
the second message were seen, then the tag would be correctly removed.

So, I think I've convinced myself that the change is actually OK. But
then I'm also wondering if perhaps we could do the processing undeferred
in all cases?

I haven't thought that through, but I'd be glad to hear your ideas.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110126/177c6bb2/attachment.pgp>