This patch is intended to greatly simplify the handling of the
"unread" tag in the emacs UI. This patch adds a new function
'notmuch-show-mark-read', that removes the "unread" tag in
notmuch-show-mode. This function is then executed as a
notmuch-show-hook, and by notmuch-show-next-message. All of the
functions that explicitly marked messages as unread are removed or
renamed.
The idea here is that the user should never have to worry about
manipulating the "unread" tag. The tag should persist until the user
actually views a message, at which point it should be automatically
removed. This patch simplifies the notmuch.el quite a bit, removing a
lot of somewhat redundant functions, and reducing clutter in the name
and key-mapping space.
The text output uses thread:<foo>, (which is a syntax directly supported
by "notmuch show"), so make the json output be "thread", "<foo>" rather
than "id", "<foo>". This should help avoid confusion of thread IDs with
message IDs, (which do use the "id" prefix in searches).
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.
We've been using --output in IRC and on the mailing list for a while,
(someone had the good sense to point out that --for would defeat
command-line completion since it's a prefix of the proposed --format).
In spite of being implemented with the word "stash" in the function
names, the documentation (and hence help strings) for each function
already use the word "Copy" to describe the action. So 'c' is a much
more natural key-binding, (particularly since 'z' didn't map to any
real word anyway).
We also use 'i' for the message ID copying of the submap. This is
intended to align mnemonically with the "id:" prefix already used
for message IDs.
Provide key bindings for stuffing various RFC822 header fields and other metadata
into the emacs kill-ring as text. The bindings are as follows:
z F notmuch-show-stash-filename
z T notmuch-show-stash-tags
z c notmuch-show-stash-cc
z d notmuch-show-stash-date
z f notmuch-show-stash-from
z m notmuch-show-stash-message-id
z s notmuch-show-stash-subject
z t notmuch-show-stash-to
The previous version would crash when a key was bound to a sparse
keymap, since apparently these are not straightforward lists. The
usage of map-keymap is a bit obscure: it only has side-effects, no
return value.
Return the corresponding header field for the current message as a
string. These are thin wrappers around notmuch-show-get-header, which
means they each cause a full parse of the RFC822 header. The main idea
is to fix an api.
This function parses the displayed message to recover header
fields. It uses mailheader.el to do the actual header parsing, after
preprocessing to remove indentation. It relies on the variables
notmuch-show-message-begin-regexp, notmuch-show-header-begin-regexp,
and notmuch-show-message-end-regexp.
Eric reported that a particular thread was non-functional in the
notmuch-search mode in the emacs client. It was easy enough to trace
the bug down to a broken regular expression (using ':' instead of
';'). The bug would be triggered by a message with ':' in the
From address.
This is something I hope to add to the test suite as soon as we have
support for testing the emacs interface there.
We temporarily override the mm-inline-media-tests variable so that the
only parts inserted into the temporary buffer (and lost) are those
parts that the user has already seen in the notmuch-show buffer.
Anything else, (such as images), will now be left to be handled via
mailcap, just like other attachment types.
The infinite loop was triggered by a message consisting of a single
attachment within the body, (and no "part") tags.
We need to do things in response to this bug (beyond this specific
fix):
1. Create a test suite that exercises our emacs frontend so that bugs
like this do not come back to haunt us after we fix them once.
2. Switch from our ad-hoc regexp based search of message-part delimeters
to known-good code for parsing a structured document, (for example,
the outstanding JSON patches).
Now instead of requiring every single message be parsed, we now check
the Content-type in the parsed headers and only do HTML inlining if it's
text/html
Thanks to Michal Sojka <sojkam1@fel.cvut.cz> for pointing out the
correct fix, which I verified in the freely-available WG14/N1124 draft
(from the C99 working group) which is available here:
http://www.open-std.org/JTC1/SC22/wg14/www/docs/n1124.pdf
The sequential identifiers have the advantage of being guaranteed to
be unique (until we overflow a 64-bit unsigned integer), and also take
up half as much space in the "notmuch search" output (16 columns
rather than 32).
This change also has the side effect of fixing a bug where notmuch
could block on /dev/random at startup (waiting for some entropy to
appear). This bug was hit hard by the test suite, (which could easily
exhaust the available entropy on common systems---resulting in large
delays of the test suite).
This makes it easier to see folders with messages.
Eliding empty folders is togged with the 'e' binding.
Signed-off-by: Keith Packard <keithp@keithp.com>
This allows the user to compose new mail from the folder view, and
also to use <space> to show the current folder.
Signed-off-by: Keith Packard <keithp@keithp.com>
- rename notmuch-show-citation-lines-min to n-s-c-l-prefix
- call forward-line with the appropriate parameter to adjust
region to be hidden.
- change citation button text so that it makes (some) sense when citation is shown
Reviewed-by: Kan-Ru Chen <kanru@kanru.info>
This is a fairly intrusive rewrite.
- I pulled the common code for the signature and citation case out
into a separate function. This is not so much shorter, but I think it
will be easier to maintain.
- I replaced the sequence of (looking-at blah) (forward-line) with a single
re-search-forward per citation.
New variables
- notmuch-show-signature-button-format, notmuch-show-citation-button-format
Allow customization of button text.
- notmuch-show-citation-lines-min
Do not buttonize citations below the given threshold.
Reviewed-by: Kan-Ru Chen <kanru@kanru.info>
It's a simple optimization to look at a message and check that the
existing tags are actually different than the tags we are setting
before we do anything.
For my mail store this takes a "notmuch restore" that does nothing
from about 10 minutes down to 1 minute, so there's a significant
speedup here.
We do this all the time, but at least emacs is kind enough to remind us,
(when compiling), that next-line is only intended for interactive use,
and we should use forward-line inside of lisp code.
I really missed this feature. Added notmuch-show-toggle-current-body and
notmuch-show-toggle-current-header and bind them to 'b' and 'h'.
Signed-off-by: Kan-Ru Chen <kanru@kanru.info>
These tests were surprisingly simple to write---not much code at all
and most of them worked the first time even with hand-prepared
versions of the expected output.
The previous generate_message function is what's needed when testing
"notmuch new". But after that, we never want to generate a message
without also adding it to the index. So create a new add_message
function with this convenience.
If we had external users of this filter then they might expect some of
these macros to exist. But since this is just internal, that's just
unneeded noise.
With modern MIME attachments, we're already avoiding indexing the
attachments. But for old-school uuencoded data in the mail, we have
been directly indexing the encoded data as terms, (which is not useful
at all---nobody will ever ytry to search based on the seemingly random
uuencoded data).
Additionally, indexing a modestly large uuencoded file seems to make
Xapian go insane, (consuming *lots* of memory).
We fix both problems by detecting uuencoded content and not performing
any indexing of it.
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.
This is a test for the recently added feature where we detect that the
reply-to address already exists in the To: or Cc: header so will
already be replied to. In this case we want to include the From:
address in our reply, (where, otherwise we would use the Reply-To
address *instead* of the address in the From header).
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>
