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.
These were introduced as a side-effect of commit
b9eac48c22 (shame on me for doing
side-effect commits like that!).
For me, at least, compilation is now warning-free.
Notmuch reply should not be Bcc'ing the sender by default. This is
not the appropriate way to save copies of sent mail (which should
probably be handled by an Fcc header[*]) and it doesn't give the user the
option to not be bcc'd. This is really something that should be
handled by the reader UI. For instance, emacs message-mode can easily
be configured to add Bcc's if the user wishes.
[*] Carl Worth: The FCC header is now in place by default in the emacs
user-interface (and tested in the test suite) so the Bcc is ready to
be eliminated.
i is already used in a for loop at this point, so using i here again
broke notmuch-reply (it would just hang). Use j instead of i here.
Signed-off-by: Sebastian Spaeth <Sebastian@SSpaeth.de>
We want to be able to correctly guess the best From: header to use when
replying to emails. This is what we are looking at now:
1 is one of the users' mail addresses in the To: or Cc: header
2 check for an Envelope-to: header
3 check for an X-Original-To: header
4 check for a (for <email@add.res>) clause in Received: headers
5 check for the domain part of known email addresses in the
'by' part of Received headers
6 fall back to the primary email address
This patch changes the algorithm for steps 2-5 of this process. Prior to
this patch we had a first attempt to implement only step 5 - but this
broke in many email setups where mail delivery to the local machine added
additional Received: lines.
Steps 2-4 are new, step 5 now analyzes the concatenated Received: header
(this was in the previous patch) to do this analysis.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
This seems a rather unlikely case, (replying to a message that
disappears out from under us half way through the reply), but
notmuch_message_get_header is documented to return NULL in error
cases, so we might as well deal sanely with that (rather than just
crashing).
When headers contain non-ASCII characters, they are encoded according
to rfc2047. Nomtuch reply command emits the headers in the encoded
form, which makes them hard to read by humans who compose the reply.
For example instead of "Subject: Re: Rozlučka" one currently sees
"Subject: Re: =?iso-8859-2?q?Rozlu=E8ka?=".
This patch adds a new GMime filter which is used to decode headers to
UTF-8 and uses this filter when notmuch reply outputs headers.
Signed-off-by: Michal Sojka <sojkam1@fel.cvut.cz>
The previous code made too many assumptions about the (sadly not
standardized) format of the Received headers. This version should
be more robust to deal with different variations.
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
When replying to a message notmuch tries to pick the correct From
address by looking which one of a user's configured email addresses
were included in To or Cc headers of the email that is being replied to.
If none of the users email addresses are in the To or Cc headers we now
try to guess from the first (chronologically, last) Received header
which domain this email was received in and therefore which of the
email addresses to use in a reply
If that fails we still use the primary email as From email
Signed-off-by: Dirk Hohndel <hohndel@infradead.org>
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'.
This function detects whether the address in the Reply-To header
already appears in either To or Cc. So give it a name that reflects
what it does (reply_to_header_is_redundant) rather than the old name
which described one possible use of the function, (as a simple
heuristic for detecting whether a mailing list had applied reply-to
munging).
Apparently, GMime doesn't want to create a valid address list object
for an empty string. That's annoying, but it's easy enough to test for
the empty string and avoid the problem.
This change was already recommended in a comment in the original
implementation of this patch. If someone really wants to support
un-munging in the case of To: and Reply-To: having the same address
but different case, then they can provide a portable approach for
that.
Some mailing lists engage in the evil practice of changing the Reply-To
header so that replies from all mailers go to the list by default, at
the expense of not responding to the person who actually sent the
message. When this is detected, we reply to `From' and remove the
duplicate response to the mailing list. Consider a reply to the
following message.
From: Some User <some.user@example.com>
To: Sample users list <sample-users@sample.org>
Reply-To: Sample users list <sample-users@sample.org>
Prior to this patch, `notmuch reply' produces
To: Sample users list <sample-users@sample.org>,
Sample users list <sample-users@sample.org>
and after the patch,
To: Some User <some.user@example.com>,
Sample users list <sample-users@sample.org>
Signed-off-by: Jed Brown <jed@59A2.org>
This code was already duplicated. We move it to a new, shared
add_recipients_from_message function, in preparation for more
sophisticated mailing list logic.
Signed-off-by: Jed Brown <jed@59A2.org>
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>
This command only generates References, To, and Cc headers.
The purpose is primarily for use in
git send-email --notmuch id:<MESSAGE-ID>
to get proper threading and address the relevant parties. Hooks for
other SCMs may come later.
Signed-off-by: Jed Brown <jed@59A2.org>
This factors actual generation of the reply out of notmuch_reply_command
into notmuch_reply_format_default(), in preparation for other --format=
options.
Signed-off-by: Jed Brown <jed@59A2.org>
The domain is alway case insensitive, but in principle the username is
case sensitive. Few systems actually enforce this so I think a good
default is to treat the entire address as case insensitive, it will
eliminate a lot of superfluous self-addressed messages and reply from
the correct address in these cases.
Signed-off-by: Jed Brown <jed@59A2.org>
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>
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.
There are still open questions about how to correctly compute the
intended list of recipients. We'll probably need separate "reply to
sender" and "reply to all" commands at some point (unfortunately).
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.
That is, if mail was addresses to one of the "other" addresses in the
configuration file, then the reply will have its "From" header set to
that same address rather than the primary address.
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).
The advantage here is that we actually get the necessary folding of
long headers, (particularly the References header, but also things
like Subject). This also gives us parsed recipient addresses so that
we can easily elide the sender's address(es) from the recipient list
(just as soon as we have a configured value for the recipient's
address(es)).
We know take the original From: and all recipients and put them on the
To: line. We also add a "Re: " to the subject, and we add In-Reply-To:
and References: headers.
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).
