From: Carl Worth <cworth@cworth.org>
To: Marten Veldthuis <marten@veldthuis.com>, notmuch <notmuch@notmuchmail.org>
In-Reply-To: <1259830240-sup-2467@gopher.local>
References: <1259100630-13673-1-git-send-email-jan@ryngle.com>
	<87ws1583ea.fsf@yoom.home.cworth.org>
	<1259830240-sup-2467@gopher.local>
Date: Thu, 03 Dec 2009 22:17:52 -0800
Message-ID: <87r5rbfejz.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Subject: Re: [notmuch] [PATCH 0/4] Make tags applied by 'notmuch new'
 configurable.
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Thu, 03 Dec 2009 10:48:00 +0100, Marten Veldthuis <marten@veldthuis.com>=
 wrote:
> I can see one clear case where that would become a problem: mistaggings.
> If I set up something so that in 99% of the cases, it'd tag new mail
> correctly with say "inbox unread mytag", I could quickly pick the
> mistagged ones out and remove the offending tag.=20
>=20
> If you do it like above however, the autotag script would come merrily
> along and retag them.

Right. A fully automatic, rule-based tag does not allow for manual
deletion of the exact same tag, (nor even manual addition).

I've given this some thought and there are things we could do here. For
example, the automatic tag could be stored internally under a different
prefix than the manual tag of the same name. That would be enough to
support the manual addition of a tag, such that a user-level search such
as:

	tag:foo

would map internally to something like:

	(auto-tag:foo OR manual-tag:foo)

Then manual tag removal could similarly be stored as yet anther internal
prefix that would work in a negative sense. So the search for "tag:foo"
would now map to:

	((auto-tag:foo OR manual-tag:foo) AND NOT manual-tag-removal:foo) [*]

I'm not sure yet if this idea is simply clever or insanely stupid.

It does seem like we could do this and hide all of the complexity
entirely from the user. But hidden complexity can raise its head in
nasty ways. Such as "I wrote this rule in my configuration file, why
isn't it working?" (in the face of a hidden manual-tag-removal).

Another idea would be to just keep the rule-based tags strictly as
configured, explicitly prevent the user from manually adding/removing
tags of the same name. And then the user could play games like the above
in saved searches to be able to simulate manual touchups of rule-based
tags, (without the automatic vs. manual state being hidden).

Yet another idea is to keep all rule-based tagging out of the
configuration, and let the user come up with whatever scheme they most
prefer. This could still allow for the configuration to hold saved
searches, (which could stand in for rule-based tags in a lot of cases
and avoid a lot of the complexity discussed here).

So those are some of my current thoughts on the issue. And that's why I
haven't put any auto tagging into the configuration file yet.

=2DCarl

[*] Or should that be:

	(manual-tag:foo OR (auto-tag:foo AND NOT manual-tag-removal:foo))

It probably wouldn't matter in practice as presumably the addition of
the manual-tag would remove any manual-tag-removal and vice-versa.

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLGKmR6JDdNq8qSWgRAjfQAKCZxDDviUDd60PeVKyJkGoowEgYsACfeD6b
vz0M9K47VlX2UiIGcRHa2hQ=
=3KPT
-----END PGP SIGNATURE-----
--=-=-=--