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.
Since commit c51d5b3cdb we are counting
multipart containers when emitting part numbers in the "notmuch show"
output. Unfortunately, "notmuch part" wasn't updated with the same
numbering, (and the test suite is inadequate to catch this).
Fix this by adding a similar part-numbering change to "notmuch part" here.
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.
This file causes emacs to automatically set the correct style
variables to control indentation, etc. One more thing to make it
easier for everyone to collaborate with a consistent coding style.
Signed-off-by: Jameson Rollins <jrollins@finestructure.net>
Remove double quotes and flatten "foo@bar.com <foo@bar.com>" to
"foo@bar.com".
Edited-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net> (clean up
expected output for emacs tests).
Signed-off-by: Jameson Rollins <jrollins@finestructure.net>
This controls the appearance of collapsed messages in notmuch-show
mode, avoiding redundancy for repeated subject).
Remove `notmuch-show-always-show-subject'.
Signed-off-by: Jameson Rollins <jrollins@finestructure.net>
Typically used to allow a `text/html' renderer access to images which
are sent along with the HTML.
This is not enabled by default, instead the user must execute
`notmuch-show-setup-w3m' for it to take effect.
Edited-by: Carl Worth <cworth@cworth.org> Add documentation string for
notmuch-show-setup-23m and clean up warning about reference/assignment
of free variable.
Signed-off-by: Jameson Rollins <jrollins@finestructure.net>
Add a variable `notmuch-show-all-multipart/alternative-parts' that
allows the user to indicate that all candidate sub-parts of a
multipart/alternative part should be shown rather than just the
preferred part. The default is `nil', showing only the preferred part.
This is mostly a debugging aid.
Signed-off-by: Jameson Rollins <jrollins@finestructure.net>
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>
The compilation of the smtp-dummy program would fail if a build was
attempted on a system without getline. Fix this by simply including
the existing notmuch_compat_srcs variable when constructing the list
of source files for compiling smtp-dummy.
Use code from icalendar.el to convert text/x-vcalendar parts to
something suitable for use with the Emacs diary.
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 tests "notmuch show" with both --format=text and --format=json on
a message with some non-trivial MIME multipart nesting, (multiple parts
within a multipart/mixed part which is within a multipart/signed part).
The test captures the current behavior (where only the leaf nodes of
the MIME structure are emitted as a flat list---the multipart parts
are effectively ignored). We plan to soon change the json output at
least to emit an actual hierarchy matching the MIME structure, (at
which point we will update this test).
As of gcc 4.6, there are new warnings from -Wattributes along the lines of:
warning: ‘_notmuch_messages’ declared with greater visibility
than the type of its field ‘_notmuch_messages::iterator’
[-Wattributes]
To squelch these, we decorate all such containing structs with
__attribute__((visibility("default"))). We take care to let only the
C++ compiler see this, (since the C compiler would otherwise warn
about ignored visibility attributes on types).
gcc (at least as of version 4.6.0) is kind enough to point these out to us,
(when given -Wunused-but-set-variable explicitly or implicitly via -Wunused
or -Wall).
One of these cases was a legitimately unused variable. Two were simply
variables (named ignored) we were assigning only to squelch a warning about
unused function return values. I don't seem to be getting those warnings
even without setting the ignored variable. And the gcc docs. say that the
correct way to squelch that warning is with a cast to (void) anyway.
This avoids the emacs lisp compiler from emitting warnings on this
replacement code, (which warnings would be hard for us to eliminate
since we didn't write the code but copied it verbatim from emacs 23).
The problem with 'mailx' is that it's not standardized, and it doesn't
allow the -f option, which is pretty important on many sendmail
configurations.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Theses were expected failures only due to a bug in GMime (with
versions of GMime before 2.4.18). As of GMime version 2.4.18 this bug
is fixed and these tests now pass.
Now each caller of notmuch_message_get_tags only gets a new iterator,
instead of a whole new list. In principle this could cause problems
with iterating while modifying tags, but through the magic of talloc
references, we keep the old tag list alive even after the cache in the
message object is invalidated.
This reduces my index search from the 3.102 seconds before the unified
metadata pass to 1.811 seconds (1.7X faster). Combined with the
thread search optimization in b3caef1f06,
that makes this query 2.5X faster than when I started.
Even if the caller never uses the file names, there is little cost to
simply fetching the file name terms. However, retrieving the full
paths requires additional database work, so the expansion from terms
to full paths is performed lazily.
This also simplifies clearing the filename cache, since that's now
handled by the generic metadata cache code.
This further reduces my inbox search from 3.102 seconds before the
unified metadata pass to 2.206 seconds (1.4X faster).
Replace _notmuch_convert_tags with this and simplify
_create_filenames_for_terms_with_prefix. This will also come in handy
shortly to get the message file name list.
This replaces the guts of the filename list and tag list, making those
interfaces simple iterators over the generic string list. The
directory, message filename, and tags-related code now build generic
string lists and then wraps them in specific iterators. The real wins
come in later patches, when we use these for even more generic
functionality.
As a nice side-effect, this also eliminates the annoying dependency on
GList in the tag list.
This performs a single pass over a message's term list to fetch the
thread ID, message ID, and reply-to, rather than requiring a pass for
each. Xapian decompresses the term list anew for each iteration, so
this reduces the amount of time spent decompressing message metadata.
This reduces my inbox search from 3.102 seconds to 2.555 seconds (1.2X
faster).
With the previous commit, unexpected output before or between search results
would be displayed. However, trailing junk from the "notmuch search" output
would still be silently swallowed.
The most common case for an error message from "notmuch search" would be
an invalid command-line, and in that case, there would be no search results
and the trailing error message would get swallowed.
We fix the process sentinel to check for leftover data and add it to the
final buffer. We also add a test case to ensure this works.
This fixes the recently-added emacs-large-search-buffer test. This is
as simple as saving any trailing input and then pre-prepending it on
the next call.
MAny thanks to Thomas Schwinge <thomas@schwinge.name> for tracking
down this problem and contributing a preliminary version of this fix.
Rather than silently swallowing unexpected output, the emacs interface will now
display it. This will allow error messages to actually arrive at the emacs
interface (though not in an especially pretty way). This also allows for easier
investigation of the inadvertent swallowing of search results that span page
boundaries (as demonstrated by the recent added emacs-large-search-buffer test).
The page-boundary bug has been present since a commit from 2009-11-24:
93af7b5745
Many thanks to Thomas Schwinge for tracking that bug down and
contributing the test for it.
The new name is more descriptive of the bug being tested. Also, the test
is rewritten slightly so that it's much more plain to see how the bug
manifests itself, (that messages are droped from the emacs result at
regular intervals). Primarily, this is by collapsing the large blobs
used to inflate the message subjects.
The most recent commit optimized the implementation of this
function. This commit simply updates the relevant comments to match
the new implementation.
