Sometimes the internals of the implementation navigate among messages,
(as opposed to the user explicitly requesting the next message to be
shown). In these cases we don't want to remove the unread tag from the
message navigated to.
This fixes a bug where invocation of notmuch-show-next-unread-message
would clear the unread tag from all messages in a thread.
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.
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
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>
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>
We've received a user report that the hidden citations were annoying
since the user couldn't tell what was being referred to by subsequent
text. Apparently it wasn't obvious enough that the hidden citation
could be revealed by clicking or by pressing Enter. So make the button
text say as much.
In the message mentioned in the previous commit, an ASCII diagram was
included in which '>' was used as the first non-whitespace character
in a line. Notmuch previously (and mistakenly) regarded this as a
citation.
We fix this by only regarding a '>' in the first column of an email as
introducing a citation.
Thanks to Dirk Hohndel for reporting the bug. The infinite loop was first
noticed in the following message (available from the Linux kernel mailing list):
alpine.LFD.2.00.0912081304070.3560@localhost.localdomain
Note that the bug does not show up when viewing the message in
isolation---the bug was triggered only when viewing this file indented
to a depth of at least 13.
The fix is simply to use a marker rather than an integer position when
recording a point we plan to move back to later, (since inserting the
indented button causes the buffer position of the desired marker to
change).
Previously only mime parts that indicated specified a "disposition" of
"attachment" were saved. However there are time when it is important
to be able to save inline content as well. After this commit any mime
part that specifies a filename will be considered when saving
attachments.
Similar to the way thread-viewing was broken after a thread was
archived, (and recently fixed), tag manipulation has also been broken
when the thread no longer matches the current search.
This also means that the behavior of '+' and '-' are now different
than that of '*'. The '+' and '-' bindings now return to the previous
behavior old affecting all messages in the thread, (and not simply
those matching the search).
I actually prefer this behavior, since otherwise a '-' operation on a
thread might not actually remove the tag from the thread, (since it
could operate on a subset of the thread and not hit all messages with
the given tag).
So I'd now like to fix '*' to be consistent with '+' and '-', for
which we add an item to TODO.
This fixes the annoying bug of archiving a thread, and then going back
to open it and getting an error. It needs the notmuch-show API
changing patch of 1259979997-31544-3-git-send-email-david@tethera.net.
Also modify the one call to notmuch-show in notmuch.el. This makes
the call (notmuch-show thread-id) will work when there is no binding
for notmuch-search-query-string; e.g. when called from user code
outside notmuch.
Add functions notmuch-search-find-authors and notmuch-find-subject to
match notmuch-find-thread-id. These functions are just a wrapper
around get-text-property, but in principle that could change.
This reverts commit ed16edc94d.
The performance hit is just far too severe, (threads with many HTML
messages make emacs stop and pause for seconds before displaying the
thread even if most of the HTML messages are entirely hidden).
notmuch-search-filter now accepts an arbitrary query and will group if
necessary so that we get
tag:inbox AND (gravy OR biscuits)
instead of the former
tag:inbox AND gravy OR biscuits
Signed-off-by: Jed Brown <jed@59A2.org>
This is the long-awaited feature that when viewing a thread resulting
from a search, only the messages that actually match the search will
be opened initially (in addition to unread messages).
So now, it's finally useful to tag a single message in a giant thread,
and then do a search later and easily find just the single tagged
message.
There's no visible change here---we're just making the button extend
through the invisible portions of the message before the
message-summary line. The reason this is important is that it's easy
for the user to position point at the (invisible) `point-min', so we
want to ensure that there's a valid button there.
The defun special form doesn't require a progn. And the remainder
of the function was previously indented in a misleading way, (as
if each "if" was always evaluated, rather than each only being
evaluated if all the previous evaluated to nil).
This function was still implemented in terms of the old, global toggle
for visibility of unread messages, (which no longer exists). Fix it to
use the local 'invisibility-spec property on the button controlling
message visibility.
This makes these keys different than 'q' in this mode, (where 'x'
and 'q' are identical in all of the other modes currently).
The idea here is to make it easier to do non-linear reading of messages,
(such as when poking in to read just one or two threads from a search
result that returned many threads).
The dynamic scoping of emacs lisp is such that we never want to assign
to any variable unless it's something we've defined with `defvar' or
else something we're using locally via `let'.
Our documentation is long enough that I think it will be more useful
to use an entire window for it (which is easily dismissed with 'q').
This is also kinder for a user not well-initiated with emacs, for
whom the multi-window help can be confusing.
