Re: [PATCH v4 0/4] Maildir synchronization

[Michal Sojka <sojkam1@fel.cvut.cz>]

On Wed, 10 Nov 2010, Carl Worth wrote:
> > This only fails if the message is in */new and there is no */cur.
> 
> Right. I think that's a little too severe.
> 
> > I do not know if MH format has something special or it is just plain
> > files in plain directories. If the latter, the synchronzation should
> > work unless one of the directories is named 'new'.
> 
> The MH format is plain files in plain directories.
> 
> But in this case, I would contend that we don't _want_ the
> synchronization to work. The files shouldn't be getting renamed at all
> unless we are dealing with maildir.

Yes, I think this could be easily implemented.

> Neither maildir nor mh give us anything extremely reliable that we can
> use to unambiguously distinguish between them. But I think a heuristic
> of:
> 
> 	if "cur" and "new" sub-directories exist:
> 		then this directory is maildir;
> 
> And only when this heuristic passes should we be fiddling with filenames
> in maildir-specified ways.

Agreed.

> Meanwhile, I ran into one problem with my proposal. We can't use
> notmuch_message_sync_with_maildir_flags since notmuch_message_sync is an
> internal interface. The corresponding public interface actually consists
> of three or four different functions (notmuch_message_add_tag,
> notmuch_message_remove_tag, and notmuch_message_freeze/thaw). I think it
> would be quite crazy to add _with_maildir_flags variants of all of
> those.
> 
> So maybe we will need a new function for the purpose of synchronizing
> the current tags of a message to a maildir filename. So that would be,
> perhaps, notmuch_message_tags_to_maildir_flags or so?

This sounds good and allows us to get rid of
NOTMUCH_MESSAGE_FLAG_TAGS_INVALID.

> Finally, I'm also a bit unsettled about the handling of the "S"
> flag. For all the other flags it is easy to document that
> notmuch_database_add_message_with_maildir_flags simply adds the
> corresponding tag to the message. But we can't say that the presence of
> the "S" tag prevents this function from adding the "unread" tag, since
> this function never does add an "unread" tag.

But can we say the the function _removes_ the unread tag if 'S' is
present and adds it otherwise?

> Instead, the setting of "unread" is taking place at a higher-level,
> (inside "notmuch new"). So perhaps the right answer is for the library
> function to add a "seen" tag, (making the handling of 'T' consistent
> with all other tags and dropping the "inverse" field from the
> table). Then, the "notmuch new" program can query the "seen" tag to
> decide whether it should add its configured new_tags, ("inbox" and
> "unread" by default).
> 
> I do want something like that anyway, because I want to make it so that
> someone that first starts with notmuch and a large collection of maildir
> messages doesn't end up with every message tagged as "inbox" after their
> first run of "notmuch new".

I understand your point but this change would break how I use notmuch
now. My new_tags contains only "new" tag and if this tag is not added
during notmuch new the message would not be properly tagged by my
initial tagging script. I want to avoid the situation that I accidentaly
view a message in a web-mail client, which adds the 'S' flag and this
will lead to exclusion of the message from initial tagging.

If we leave the things the way they are now, it should be easy for the
user to run

  notmuch tag -inbox not tag:unread

We could also show this hint at the end of notmuch new when it is run
for the first time and all messages are tagged by inbox.

> 
> So anyway, I'm currently working on implementing what I described
> above. And I may change my mind slightly as I work through things.
> 
> I'll let you know,

Great. I've finished the additional tests, which I send as a reply to
this mail. Some test are marked as broken because I do not want to touch
C sources while you are woking on them.

-Michal