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.
Previously, we had some hard-coded keybindings mentioned in the
introductory paragraphs of the documentation for notmuch-search-mode.
Now, we take advantage of the substitute-command-keys functionality to
produce the same text by default, but to dynamically generate the
correct text in the face of the user customizing the keybindings.
As we did recently for notmuch-search-mode-map, ensure that the first
line of docuemntation for each command stands alone.
We also take advantage of the substitute-command-keys functionality
within notmuch-help so that the introductory paragraphs can talk
about key bindings by key (rather than function name) in a way that
will always be current even in the face of the user rebinding keys.
Previously, we would do only a single-level traverse of the keymap.
That meant that for a keybinding such as "M-TAB" we would just see
the prefix key ("ESC") and print that it was a keymap---never printing
the TAB nor the documentation for the command it is bound to.
Now, we do the full walk, constructing a proper description of the
full keybdinding with prefix characters, (and converting "ESC" to
"M-" for legibility).
Since notmuch-help now displays a single line of documentation from
each of these commands we ensure that the first line stands alone for
each command.
We also override some builtin commands with new commands that don't
behave any differently, but have our own notmuch-specific
documentation, (such as "select next thread" rather than "move point
to next line").
This broke when we switched to filter-based processing of search
results and added the "End of search results" line onto the end. Fix
to skip ignore that line when moving to the last thread.
When there's no more to scroll, we want to select the first thread.
This used to work, and I'm not sure when it broke, (perhaps when we
switched from post-process decorating of the search results to
filtering). Fix the calculation to work again.
The concept behind direct manipulation with mouse clicks is that
documentation shouldn't be necessary, (though my original motivation
here was simply that "<mouse-1>" was exceeding my TAB width.
This does cause a blank line to be added for the mouse binding. This
isn't directly desired, but as long as it's there we put it at a
natural place for a separator.
I had originally created this keymap in order from most important to
least important commands. But our new notmuch-help command is
presented with the list in the reverse order. So we reverse the input
so that the user sees the most important commands first.
This gives somewhat friendlier output for the '?' binding than we had
previously with `describe-mode'. First, we no longer have the various
minor modes cluttering up the output. Second the display of the
binding table uses the first line of documentation for the bound
function rather than the function name.
This silences a warning when compiling notmuch.el. The documentation
of beginning-of-buffer does say (rather emphatically) that it's not
to be used from lisp programs.
The previous location of autoload comments didn't seem to correspond
with the functions most likely to be the entry points for using
notmuch. This change adjusts them to match those likely entry points.
This patch use notmuch-tag-face showing tags in the notmuch-search-mode.
We can selectively highlight each tag by setting notmuch-tag-face-alist as below
(defface notmuch-tag-unread-face
'((((class color)) (:foreground "goldenrod")))
"Notmuch search mode face used to highligh tags.")
(defface notmuch-tag-inbox-face
'((((class color)) (:foreground "red")))
"Notmuch search mode face used to highligh tags.")
(setq notmuch-tag-face-alist '(("unread" . 'notmuch-tag-unread-face)
("inbox" . 'notmuch-tag-inbox-face)))
(require 'notmuch)
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
The most obvious bindings for save attachments are already taken. The
existing 'w' binding was bound to view the raw message. This commit
moves it to 'V' which still seems somewhat mnemonic and uses 'w' for
save (write) attachments.
Sometimes forwarding a message is preferable to replying and modifying
the set of recipients. This commit provides that ability using the
message-forward function.
The ability to temporarily create a buffer containing only the
contents of the currently selected message in notmuch show mode is
generally useful. This commit factors the majority of the code
required to do so out of notmuch-show-view-all-mime-parts into a macro
called with-current-notmuch-show-message and rewrites the original
function in terms of the macro.
A future set of commits will provide additional functionality using
the macro as well.
If there is an html mime-part in the message and it's the first part,
it gets inlined using `mm-display-part' to convert it to plain text.
The HTML content is still available as a non-text part as well.
