From: Carl Worth <cworth@cworth.org>
To: Jed Brown <jed@59A2.org>
In-Reply-To: <87skc0domr.fsf@59A2.org>
References: <87pr75q9va.fsf@yoom.home.cworth.org>
	<1259271410-15336-1-git-send-email-jed@59A2.org>
	<87fx80m5fe.fsf@yoom.home.cworth.org> <87skc0domr.fsf@59A2.org>
Date: Fri, 27 Nov 2009 21:48:33 -0800
Message-ID: <877htbtd1q.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Cc: notmuch@notmuchmail.org
Subject: Re: [notmuch] [PATCH 1/2] New function notmuch-search-operate-all:
 operate on all messages in the current query.
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Fri, 27 Nov 2009 15:32:44 +0100, Jed Brown <jed@59A2.org> wrote:
> On Fri, 27 Nov 2009 06:02:45 -0800, Carl Worth <cworth@cworth.org> wrote:
> > Since this operates via a single call to "notmuch tag" you might mention
> > here that all tag removals occur before any tag additions.
>=20
> I was unaware of this point, if I do
>=20
>   notmuch tag -inbox +star tag:inbox some-expression
>=20
> I will have starred nothing?

Oh no, it's not that.

It does one search and then does a single pass over all the messages
returned. So the above will star things.

The clarification about removing and adding really only matters if you
have the same tag appearing as both -foo and +foo in the same command
line, (which doesn't seem that useful, but there you have it).

I don't recall now why I made the special effort to handle tag removal
before tag addition rather than just applying tag changes in order. But
since that's what the current "notmuch tag" code does, I thought I
should point it out.

> > > +	(unless (string-match-p "^[\+\-][_\+\-\\w]+$" (car words))
> > > +	  (error "Action must be of the form `+thistag -that_tag'"))
> >=20
> > The error message has inconsistent "thistag" and "that_tag".
>=20
> That was somewhat intentional to illustrate that non-alphanumeric
> characters could be used in tags.  Should the alphabet for tags be based
> on a whitelist or blacklist?  It would be rather hard to validate a tag
> operation when there is no assumption/restriction on the alphabet.

Yeah, that's something we need to document. The current interface does
use space-separated tag lists without any escaping. But the command line
doesn't yet impose any restriction on tag names, and I did accidentally
add a tag once of just " " (oops!).

We should nail this down so that interface authors can know how to
validate things consistently. Any suggestions?

=2DCarl

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFLELmy6JDdNq8qSWgRAqYTAJ9TUEBaw4AnaM6e501vABitworrAQCfR3sp
KICLK+YlzhoIscT4ipXpcEA=
=iq+/
-----END PGP SIGNATURE-----
--=-=-=--