C99 stdbool turned 18 this year. There really is no reason to use our
own, except in the library interface for backward
compatibility. Convert the cli and test binaries to stdbool.
As the Linux man page states: "Each invocation of va_start() must be
matched by a corresponding invocation of va_end() in the same
function." Detected by cppcheck.
The 'insert' command will be better served if parse_tag_command_line
modifies a pre-populated list (of new.tags) instead of clobbering the
list outright. The sole existing caller, notmuch_tag_command, is
unaffected by this change.
Move an error condition specific to the 'tag' command out of
parse_tag_command_line so that parse_tag_command_line can be used for
the forthcoming 'insert' command.
Command line parsing is factored out into a function
parse_tag_command_line in tag-util.c.
There is some duplicated code eliminated in tag_query, and a bunch of
translation from using the bare tag_op structs to using that tag-utils
API.
This switches the new batch-tag format away from using a home-grown
hex-encoding scheme for message IDs in the dump to simply using Xapian
queries with Xapian quoting syntax.
This has a variety of advantages beyond presenting a cleaner and more
consistent interface. Foremost is that it will dramatically simplify
the quoting for batch tagging, which shares the same input format.
While the hex-encoding is no better or worse for the simple ID queries
used by dump/restore, it becomes onerous for general-purpose queries
used in batch tagging. It also better handles strange cases like
"id:foo and bar", since this is no longer syntactically valid.
The memory usage discipline of tag_op_list_t is never to free the
internal array of tag operations before freeing the whole list, so it
makes sense to take advantage of hierarchical de-allocation by talloc.
By not relying on the context passed into tag_parse_line, we can allow
tag_op_list_t structures to live longer than that context.
The idea is not to bother with restore operations if they don't change
the set of tags. This is actually a relatively common case.
In order to avoid fancy datastructures, this method is quadratic in
the number of tags; at least on my mail database this doesn't seem to
be a big problem.
These are meant to be shared between notmuch-tag and notmuch-restore.
The bulk of the routines implement a "tag operation list" abstract
data type act as a structured representation of a set of tag
operations (typically coming from a single tag command or line of
input).
