In case last input for batch tagging was either invalid or skippable
line, notmuch command exited with non-zero value.
After this change if there is at least one invalid line, notmuch
command will exit with non-zero value. Additionally, skipped lines
(last or other) doesn't cause non-zero value to be returned.
There is a bug in the current notmuch code with w3m and invisible
parts. w3m sets a keymap, and if we have a hidden [text/html] point
at the start of the following line still gets this w3m keymap which
causes some strange effects. For example, RET gives an error "No URL
at Point" rather than hiding the message, <down> goes to the next link
rather than just down a line.
These keybinding are also inconvenient when the text/html part is
displayed so we ask w3m not to install a keymap.
This is only likely to be a problem for emacs 23 as shr is preferred
as html renderer on emacs 24 (although the user can set the renderer
to w3m even on emacs 24).
This solution was suggested by Tomi Ollila <tomi.ollila@iki.fi>
Checking and propagating tag_op_list_apply() errors is especially
important with batch tagging, as the processing of the batch input
would not stop otherwise. Additionally this sets the exit code, which
is useful in scripts.
Amended by: David Bremner
This test also serves as documentation of the quoting
requirements. The comment lines are so that it exactly matches the man
page. Nothing more embarrassing than having an example in the man page
fail.
The (now fixed) bug that this test revealed is that unquoted
message-ids with whitespace or other control characters in them are
split into several tokens by the Xapian query parser.
This is based on the similar test for notmuch restore, but the parser
in batch tagging mode is less tolerant of a few cases, in particular
those tested by illegal_tag.
Add support for batch tagging operations through stdin to "notmuch
tag". This can be enabled with the new --batch command line option to
"notmuch tag". The input must consist of lines of the format:
+<tag>|-<tag> [...] [--] <query> [...]
Each line is interpreted similarly to "notmuch tag" command line
arguments. The delimiter is one or more spaces ' '. Any characters in
<tag> MAY be hex encoded with %NN where NN is the hexadecimal value of
the character. Any ' ' and '%' characters in <tag> and MUST be hex
encoded (using %20 and %25, respectively). For future-proofing, any
'"' characters in <tag> SHOULD be hex-encoded.
Any characters that are not part of <tag> or
MUST NOT be hex encoded.
<query> is passed verbatim to Xapian
Leading and trailing space ' ' is ignored. Empty lines and lines
beginning with '#' are ignored.
Signed-off-by: Jani Nikula <jani@nikula.org>
Hacked-like-crazy-by: David Bremner <david@tethera.net>
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.
While one comment in generated .notmuch-config file looked good in the
source file notmuch-config.c, the generated output was inconsistently
wide -- even breaking the 80-column boundary.
We recently switched to popping up a buffer to report CLI errors, but
this was too intrusive, especially for transient errors and especially
since we made fewer things ignore errors. This patch changes this to
display a basic error message in the minibuffer (using Emacs' usual
error handling path) and, if there are additional details, to log
these to a separate error buffer and reference the error buffer from
the minibuffer message. This is more in line with how Emacs typically
handles errors, but makes the details available to the user without
flooding them with the details.
Given this split, we pare down the basic message and make it more
user-friendly, and also make the verbose message even more detailed
(and more debugging-oriented).
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.
When we switch to using regular Xapian queries in the dump format, \n
will cause problems, so we disallow it. Specially, while Xapian can
quote and parse queries containing \n without difficultly, quoted
queries containing \n still span multiple lines, which breaks the
line-orientedness of the dump format. Strictly speaking, we could
still round-trip these, but it would significantly complicate restore
as well as scripts that deal with tag dumps. This complexity would
come at absolutely no benefit: because of the RFC 2822 unfolding
rules, no amount of standards negligence can produce a message with a
message ID containing a line break (not even Outlook can do it!).
Hence, we simply disallow it.
This parses the subset of Xapian's boolean term quoting rules that are
used by make_boolean_term. This is provided as a generic string
utility, but will be used shortly in notmuch restore to parse and
optimize for ID queries.
This is now a generic boolean term quoting function. It performs
minimal quoting to produce user-friendly queries.
This could live in tag-util as well, but it is really nothing specific
to tags (although the conventions are specific to Xapian).
The API is changed from "caller-allocates" to "readline-like". The
scan for max tag length is pushed down into the quoting routine.
Furthermore, this now combines the term prefix with the quoted term;
arguably this is just as easy to do in the caller, but this will
nicely parallel the boolean term parsing function to be introduced
shortly.
This is an amalgamation of code written by David Bremner and myself.
Previously, restore would abort if a message ID in the dump was
missing. Furthermore, it would only report this as a warning. This
patch makes it distinguish abort-worthy lookup failures like
out-of-memory from non-fatal failure to find a message ID. The former
is reported as an error and causes restore to abort, while the latter
is reported as a warning and does not cause an abort.
This restores 0.14's non-fatal handling of missing message IDs in
restore (though 0.14 also considered serious errors non-fatal; we
retain the new and better handling of serious errors).
This patch corrects several undesirable behaviours:
1) Empty files were not detected, leading to buffer read overrun.
2) An initial blank line cause restore to silently abort
3) Initial comment line caused format detection to fail
The argument handling in notmuch.c seems due for an overhaul, but
until then use an environment variable to specify a location to write
the talloc leak report to. This is only enabled for the (interesting)
case where some notmuch subcommand is invoked.
We add a hook to the show buffer in the message window to close the
message window when that buffer quits. It checks that the
message-window is still displaying the show-message buffer and then
closes it.
In id:87vcc2q5n2.fsf@nikula.org, Jani points out a memory leak in the
current version of the sup restore code. Among other things, this test
is intended to verify a fix for that leak.
The idea is run some code under valgrind --leak-check=full and report
a summary, leaving the user to peruse the log file if they want.
We go to some lengths to preserve the log files from accidental
overwriting; the full corpus takes about 3 hours to run under valgrind
on my machine.
The naming of the log directories may be slightly controversial; in
the unlikely event of two runs in less than a second, the log will be
overwritten. A previous version with mktemp+timestamp was dismissed as
overkill; just mktemp alone does not sort nicely.
One new test is included, to check notmuch new for memory leaks.
This is almost entirely renaming files, except for updating a few
references to those file names, and changing the makefile target.
A new set of memory tests will be run separately because they take
much longer.
Previously running search or pick from the pick buffer did not close
the message pane (if open). This meant that then new search ends up in
a very small window. Fix this so that the message pane is
shut. However, make it so that the pane is shut after the search
string is entered in case the user is basing the search on something
in the current message.
Apparently as of GMime 2.4, you don't need to call
internet_address_list_destroy anymore, but you still need to call
g_object_unref (from the GMime Changelog).
On the medium performance corpus, valgrind shows "possibly lost"
leakage in "notmuch new" dropping from 7M to 300k.
The message->headers hash table values get data returned by
g_mime_utils_header_decode_text ().
The pointer returned by g_mime_utils_header_decode_text is from the
following line in rfc2047_decode_tokens
return g_string_free (decoded, FALSE);
The docs for g_string_free say
Frees the memory allocated for the GString. If free_segment is TRUE
it also frees the character data. If it's FALSE, the caller gains
ownership of the buffer and must free it after use with g_free().
The remaining frees and allocations referencing to message->headers hash
values have been changed to use g_free and g_malloc functions.
This combines and completes the changes started by David Bremner.
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.
Previously notmuch_restore_command returned 0 if tag_message returned
a non-zero (failure) value. This is wrong, since non-zero status
indicates something mysterious went wrong with retrieving the message,
or applying it.
There was also a failure to check or propagate the return value from
tag_op_list_apply in tag_message.
Now that the invisibility display of parts is present we no longer
need to force the display of all multipart/alternatives: users can
toggle them for themselves when needed.
This adds a button action to show hidden parts. In this version "RET"
toggles the visibility of any part which puts content in the buffer
(as opposed to attachments such as application/pdf).
The button is used to hide parts when appropriate (eg text/html in
multipart/alternative).
