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.
Rather than tagging the everything in the thread. This is arguably more
desirable behavior and is consistent with clearly desirably behavior of
notmuch-search-operate-all.
Note that this change applies indirectly to
notmuch-search-archive-thread (which is actually equivalent behavior
since this function is primarily used when browsing an inbox).
Signed-off-by: Jed Brown <jed@59A2.org>
It is often convenient to change tags on several messages at once. This
function applies any number of tag whitespace-delimited tag
modifications to all messages matching the current query.
I have bound this to `*'.
Signed-off-by: Jed Brown <jed@59A2.org>
Make sure we use notmuch-search-oldest-first to decide the how
the search result should be displayed. This helps to set the
value to nil and have latest mail shown first
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
When removing a tag from a message or thread, build a completion buffer
which contains only tags that the message or thread has really set.
Signed-off-by: Jan Janak <jan@ryngle.com>
Several commands ask the user for a tag name. With this feature the
user can just press tab and Emacs automatically retrieves the list of
all existing tags from notmuch database with 'notmuch search-tags' and
presents a completion buffer to the user.
This feature is very useful for users who have a large number of tags
because it saves typing and minimizes the risk of typos.
Signed-off-by: Jan Janak <jan@ryngle.com>
We want to allow the user to be able to use search expressions with
parentheses and semi-colons, etc. and we definitely don't want the
shell interpreting those!
Previously, our emacs interface was waiting for the "notmuch search"
to complete before it would display anything. Now, we execute the
process asyncrhonously and filter results as they come in.
This takes advantage of the recent work to make "notmuch search"
results stream out steadily. The result is that some search results
will be available nearly instantly and the user can navigate and view
those while additional results continue loading.
Having actually implemented this, I realized that my
initial approach of providing a function to configure
a button was wrong. Instead I've replaced that with
button types. This then makes it possible to provide
the fully expanded view when all threads in a message
are unread.
It also has the potential to allow global-expansion functions
if that is desireable
