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.
> 
> I was unaware of this point, if I do
> 
>   notmuch tag -inbox +star tag:inbox some-expression
> 
> 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'"))
> > 
> > The error message has inconsistent "thistag" and "that_tag".
> 
> 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?

-Carl