This fixes the recently-added test case (in test/multipart)
demonstrating corruption of binary parts that happen to contain CRLF
pairs.
We restore the original code from show_one_part_content to
format_part_content_raw. Then, for good measure, we rename
show_part_content to the more descriptive show_text_part_content and
add an internal error if it is ever called with a non-text part.
This adds support for decrypting PGP/MIME-encrypted parts to
notmuch-show and notmuch-reply. The --decrypt option implies
--verify. Once decryption (and possibly signature verification) is
done, a new part_encstatus formatter is emitted, the part_sigstatus
formatter is emitted, and the entire multipart/encrypted part is
replaced by the contents of the encrypted part.
At the moment only a json part_encstatus formatting function is
available, even though decryption is done for all formats. Emacs
support to follow.
This is primarily for notmuch-show, although the functionality is
added to show-message. Once signatures are processed a new
part_sigstatus formatter is emitted, and the entire multipart/signed
part is replaced with the contents of the signed part.
At the moment only a json part_sigstatus formatting function is
available. Emacs support to follow.
The original work for this patch was done by
Daniel Kahn Gillmor <dkg@fifthhorseman.net>
whose help with this functionality I greatly appreciate.
Future improvements (eg. crypto support) will require adding new part
header. By breaking up the output of part headers from the output of
part content, we can easily out new part headers with new formatting
functions.
Since message/rfc822 parts are really just a special kind of
multipart, we here normalize the handling of the two. This will
provide access to sub-parts of message/rfc822 parts, which was
previously unavailable.
Outputting of single MIME parts is moved to an option of notmuch show,
instead of being handled in it's own sub-command. The recent rework
of multipart mime allowed for this change but consolidating part
handling into a single recursive function (show_message_part) that
includes formatting. This allows for far simpler handling single
output of a single part, including formatting.
We rename here in order to make do_show_single into a generic function
for handling output of just a single message, or which format=raw is a
special case. The raw case is handled by setting a new parameter,
params.raw, which is used to tell do_show_single to output a single
message as a raw file.
This is mostly in preparation for much improved part handling to
follow imminently.
A new field "part_sep" is added to the notmuch_show_format structure,
to be used for part separation. This is cleaner than the "first"
argument that was being passed around to the part arguments, and
allows the function that handles overall part output formatting
(show_message_part) to directly handle when outputting the separator.
This simplifies the passing of arguments to the show functions. This
will be very useful as we accumulate more parameters that will need to
be passed. Currently only the entire_thread parameter is passed this
way.
Various show_message* functions require formatting functions, which
were previously being passed individually as arguments. Since we will
need to be needing to passing in more formatting function in the
future (ie. for crypto support), we here modify things so that we just
pass in the entire format structure. This will make things much
simpler down the line as we need to pass in new format functions.
We move the show_format structure into notmuch-client.c as
notmuch_show_format. This also affects notmuch-reply.c, so we create
a mostly-empty format_reply to pass the reply_part function to
show_message_body.
It's simply one more property of a MIME part that might be useful, and
json makes it so easy to add additional properties.
Signed-off-by: Jameson Rollins <jrollins@finestructure.net>
Previously, notmuch show flattened all output, losing information
about the nesting of the MIME hierarchy. Now, the output is properly
nested, (both in the --format=text and --format=json output), so that
clients can analyze the original MIME structure.
Internally, this required splitting the final closing delimiter out of
the various show_part functions and putting it into a new
show_part_end function instead. Also, the show_part function now
accepts a new "first" argument that is set not only for the first MIME
part of a message, but also for each first MIME part within a series
of multipart parts. This "first" argument controls the omission of a
preceding comma when printing a part (for json).
Many thanks to David Edmondson <dme@dme.org> for originally
identifying the lack of nesting in the json output and submitting an
early implementation of this feature. Thanks as well to Jameson Graef
Rollins <jrollins@finestructure.net> for carefully shepherding David's
patches through a remarkably long review process, patiently explaining
them, and providing a cleaned up series that led to this final
implementation. Jameson also provided the new emacs code here.
Previously, the outer multipart part of any multipart/mixed,
multipart/signed, etc. MIME message was silently omitted from the
"notmuch show" output. This prevented any client from correctly
determining to which parts a signature applies, for example.
Now, we actually emit these parts as their own parts. The output is
still flattened---the contained parts are not yet included "within"
the multipart part---so it's still not possible to determine to which
parts a signature applies, but this is one step along the path.
The test suite is updated to reflect this change, (though we'll
eventually want to fix the emacs interface to not display buttons for
the multipart enclosure parts as there's nothing useful for the user
to actually do with them).
This is part of an effort to avoid proliferation of excessive
top-level notmuch commands. Also, "raw" better captures the
functionality here, (as opposed to "cat" which is a fairly oblique
reference to a bad Unix abbreviation whose metaphor doesn't work here
since "notmuch cat" operates only on a single message and hence cannot
"con'cat'enate" anything).
This command outputs a raw message matched by search term to the
standard output. It allows MUAs to access the messages for piping,
attachment manipulation, etc. by running notmuch cat rather then
directly access the file. This will simplify the MUAs when they need
to operate on a remote database.
Edited-by: Carl Worth <cworth@cworth.org>: Remove trailing whitespace,
add missing "test_done" to new test script to avoid "Unexpected exit"
error.
We don't love the mbox format, but it's still sometimes the most
practical way to share a collection of messages as a single file.
Here we implement the "mboxrd" variant of the mbox file format. This
variant applies reversible escaping by prefixing a '>' character to
all lines in the email messages matching the regular expression:
"^>*From "
This allows the escaping to be reliably removed. A reader should remove
a '>' from any line matching the regular expression:
"^>>*From "
More details on the mboxrd formats (and others as well) can be found
here:
http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/mail-mbox-formats.html
Micah Anderson reported an issue where a message failed to display in
the emacs interface, (it instead gave an error, "json-read-string: Bad
string format").
Micah tracked this down to the json output from "notmuch show" being
interrupted by a GMime error message:
gmime-CRITICAL **: g_mime_stream_filter_add: assertion
`GMIME_IS_FILTER (filter)
I tracked this down further to notmuch passing a NULL value to
g_mime_stream_filter_add. And this was due to calling
g_mime_filter_charset_new with a value of "unknown-8bit".
So we add a test message withe a Conten-Type of "text/plain;
charset=unknown-8bit" from Micah's message. Then we fix "notmuch show"
to test for NULL before calling g_mime_stream_filter_add. Bug fixed.
A new 'part' subcommand allows the user to extract a single part from
a MIME message. Usage:
notmuch part --part=<n> <search terms>
The search terms must match only a single message
(e.g. id:foo@bar.com). The part number specified refers to the part
identifiers output by `notmuch show'. The content of the part is
written the stdout with no formatting or identification marks. It is
not JSON formatted.
Include a 'date_unix' and 'date_relative' field in the JSON output for
each message. 'date_relative' can be used by a UI implementation,
whereas 'date_unix' is useful when scripting.
I ran into this while looking at the vim plugin. Vim's system() call
redirects output to a file and it was missing many of the part{ lines.
If stream_stdout is setup too early, it will overwrite the part start
when notmuch is redirected to a file.
Reviewed-by Carl Worth <cworth@cworth.org>: GMime is calling fseek
before every write to reset the FILE* to the position it believes is
correct based on the writes it has seen. Our code was getting
incorrect results because our GMime writes were interleaved with
non-GMime writes via printf.
The bug appears when writing to a file because it's seekable, but not
when writing to a pipe which is not.
The previous json patches forgot to add the notmuch tags to the json
output. This is inconsistent to the text output so here they are. We
just output a 'tags' field that sends notmuch tags as a json array.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
This is a fairly old regression. There has always been code to avoid
printing empty headers (such as Cc or Bcc with no values), but it has
been broken since notmuch_message_get_header was changed to return
an empty string rather than a NULL pointer for these fields.
We rename 'has_more' to 'valid' so that it can function whether
iterating in a forward or reverse direction. We also rename
'advance' to 'move_to_next' to setup parallel naming with
the proposed functions 'move_to_first', 'move_to_last', and
'move_to_previous'.
In the case of notmuch-show, "--format=json" also implies
"--entire-thread" as the thread structure is implicit in the emitted
document tree.
As a coincidence to the implementation, multipart message ID numbers are
now incremented with each part printed. This changes the previous
semantics, which were unclear and not necessary related to the actual
ordering of the message parts.
When "notmuch show" was recently modified to not show an entire thread
by default, it also lost all capability to properly order the messages
in a thread and to print their proper depth. For example, the command:
notmuch show thread:6d5e3e276461188c5778c9f219f63782
had dramatically different output than:
notmuch show --entire-thread thread:6d5e3e276461188c5778c9f219f63782
even though both commands were selecting and displaying the same set
of messages. The first command would diplay them "flat", (all with
depth:0), and in strict date order; while the second command would
display them "nested" (with depth based on threading), and in thread
order.
We now fix "notmuch show" without the --entire-thread option to also
display nested and thread-ordered messages.
If some messages in the thread are not included in the displayed
results, then they are not counted when computing depth values.
This patch changes the default behaviour of notmuch show to display only
messages that match the search expression. However, --entire-thread
option is provided to display all messages in threads that matched the
search expression.
It is deemed that will be more useful for human users on the command line.
Scripts can be modified to include the --entire-thread option so that they
can display all messages once more.
Example:
$ notmuch search subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b
thread:23d99d0f364f93e90e15df8b42eddb5b July 31 [4/12] Johan Herland; [RFCv2 00/12] Foreign VCS helper program for CVS repositories (inbox unread)
Note that in this thread 4 out of 12 messages matched. The default show
behaviour is to show only those messages that match:
$ notmuch show subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b | grep 'message{' | wc -l
4
With the --entire-thread option the output will contain all dozen
messages:
$ notmuch show --entire-thread subject:git AND thread:23d99d0f364f93e90e15df8b42eddb5b | grep 'message{' | wc -l
12
Signed-off-by: Bart Trojanowski <bart@jukie.net>
As per Carl's request, this patch corrects the only value defined under
the notmuch_message_flag_t enum typedef to match the name of the type.
Signed-off-by: Bart Trojanowski <bart@jukie.net>
The show command outputs all messages in the threads that match the
search-terms. This patch introduces a 'match:[01]' entry to the 'message{'
line output by the show command. Value of 1 indicates that the message is
matching the search expression.
Signed-off-by: Bart Trojanowski <bart@jukie.net>
This was a poor workaround around the fact that the existing
notmuch_threads_t object is implemented poorly. It's got a fine
iterartor-based interface, but the implementation does all of the
work up-front in _create rather than doing the work incrementally
while iterating.
So to start fixing this, first get rid of all the hacks we had working
around this. This drops the --first and --max-threads options from the
search command, (but hopefully nobody was using them
anyway---notmuch.el certainly wasn't).
Pass the message through the charset filter so that we can view
messages wrote in different charset encoding.
Signed-off-by: Kan-Ru Chen <kanru@kanru.info>
We only rarely need to actually open the database for writing, but we
always create a Xapian::WritableDatabase. This has the effect of
preventing searches and like whilst updating the index.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Carl Worth <cworth@cworth.org>
In particular, notmuch tag -inbox "" tended to take a long time to
run, happened if you hit 'a' on a blank line in the search view and
probably didn't have the desired effect.
Signed-off-by: Keith Packard <keithp@keithp.com>
This really should be impossible---if there are no messages, then what
was the thread object created from? During recent debugging, it was
useful to have this error detected and reported.
We now properly analyze the in-reply-to headers to create a proper
tree representing the actual thread and present the messages in this
correct thread order. Also, there's a new "depth:" value added to the
"message{" header so that clients can format the thread as desired,
(such as by indenting replies).
It's funny that I picked up the habit of always including a space
before a left parenthesis from Keith, and now he's in the habit of
contributing code without it.
The library interface now allows the caller to do incremental searches,
(such as one page of results at a time). Next we'll just need to hook
this up to "notmuch search" and the emacs interface.
All of the following commands:
notmuch dump
notmuch reply
notmuch restore
notmuch search
notmuch show
notmuch tag
were calling notmuch_database_open with an argument of NULL. This was
a legitimate call until the recent addition of configuration, after
which it is expected that all commands will lookup the correct path in
the configuration file. So fix all these commands to do that.
Also, while touching all of these commands, we fix them to use the
talloc context that is passed in rather than creating a local talloc
context. We also switch from using goto for return values, to doing
direct returns as soon as an error is detected, (which can be leak
free thanks to talloc).
Reviewed-by: Carl Worth <cworth@cworth.org>
Keith wrote all the code here against notmuch before notmuch.c was
split up into multiple files. So I've pushed the code around in
various ways to match the new code structure, but have generally tried
to avoid making any changes to the behavior of the code.
I did fix one bug---a missing call to g_mime_stream_file_set_owner in
show_part which would cause "notmuch show" to go off into the weeds
when trying to show multiple messages, (since the first stream would
fclose stdout).
Now that the client sources are alone here in their own directory,
(with all the library sources down inside the lib directory), we can
break the client up into multiple files without mixing the files up.
The hope is that these smaller files will be easier to manage and
maintain.
