From: Carl Worth <cworth@cworth.org>
To: Michal Sojka <sojkam1@fel.cvut.cz>, notmuch@notmuchmail.org
Subject: Re: [PATCH v4 0/4] Maildir synchronization
In-Reply-To: <874obp325b.fsf@steelpick.2x.cz>
References: <87tyk3vpxd.fsf@wsheee.2x.cz>
	<1288560558-18915-1-git-send-email-sojkam1@fel.cvut.cz>
	<877hgsrjau.fsf@yoom.home.cworth.org> <87d3qhq527.fsf@resox.2x.cz>
	<874obrmww9.fsf@yoom.home.cworth.org>
	<87iq066cbd.fsf@steelpick.2x.cz>
	<87oc9ykzae.fsf@yoom.home.cworth.org>
	<877hgm2hjg.fsf@steelpick.2x.cz>
	<87lj52knbp.fsf@yoom.home.cworth.org>
	<874obp325b.fsf@steelpick.2x.cz>
User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Wed, 10 Nov 2010 08:48:54 -0800
Message-ID: <87fwv9ktu1.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Wed, 10 Nov 2010 11:26:40 +0100, Michal Sojka <sojkam1@fel.cvut.cz> wrot=
e:
> > 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?
>=20
> This sounds good and allows us to get rid of
> NOTMUCH_MESSAGE_FLAG_TAGS_INVALID.

Yes. And I'm now pursuing simply two new synchronization functions, (as
opposed to the _with_maildir_flags variant of _add_message I proposed
earlier). So the two new functions are:

	notmuch_message_maildir_flags_to_tags
and	notmuch_message_tags_to_maildir_flags

> But can we say the the function _removes_ the unread tag if 'S' is
> present and adds it otherwise?

I think so. I ended up getting close to this with the code I was writing
yesterday. I eventually had the original (non-maildir-related)
notmuch_database_add_message adding the "unread" tag (which is a new
behavior) and the _add_message_with_maildir_flags removing it if
necessary.

The semantics will be slightly different with the explicit flags_to_tags
function, but I think I'll get this right.

> 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.

And of course I found the same problem with my own setup. ;-)

So the tag named configured in [new.tags] will need to be applied
unconditionally to all new messages, (as currently documented). I was
getting concerned when my patches started adding an "unread" tag to new
messages (even without [maildir.synchronize_flags] configuration) and
the existing configuration wouldn't allow a user to prevent that.

But perhaps with the new functions proposed above we can avoid that
problem.

>   notmuch tag -inbox not tag:unread
>=20
> 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.

Yes. That might be the right answer.

> 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.

Thanks!

In addition to this test:

       +test_begin_subtest 'Duplicated message is tagged according to the d=
uplicate'
       +cp "$MAIL_DIR/cur/msg-003" "$MAIL_DIR/cur/msg-003-dup:2,RS"=20

I'd like to see a similar test that starts with "some-message:2,RS" and
then copies it to "some-message". When we add this message would we
expect the "replied" tag to be removed and the "unread" tag added?

I'm still trying to work out exactly how the
notmuch_message_maildir_flags_to_tags function should be documented,
(whereas notmuch_message_tags_to_maildir_flags seems entirely obvious).

Thanks,

=2DCarl

=2D-=20
carl.d.worth@intel.com

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFM2sz26JDdNq8qSWgRAhalAJ4i2P6Y5tXuVRc0bbkMBntzMN/UIgCfeNbl
KyhkZkL6JcW45i8/Wq93R/I=
=QPd6
-----END PGP SIGNATURE-----
--=-=-=--