If the car of an element in notmuch-search-result-format is a
function, insert the result of calling the function into the buffer.
This allows a user to generate custom fields in the output of a search
result. For example, with:
(defun -notmuch-result-flags (format-string result)
(let ((tags-to-letters '(("flagged" . "!")
("unread" . "u")
("mine" . "m")
("sent" . "s")
("replied" . "r")))
(tags (plist-get result :tags)))
(format format-string
(mapconcat (lambda (t2l)
(if (member (car t2l) tags)
(cdr t2l)
" "))
tags-to-letters ""))))
(setq notmuch-search-result-format '((-notmuch-result-flags . "%s ")
("date" . "%12s ")
("count" . "%9s ")
("authors" . "%-30s ")
("subject" . "%s ")
("tags" . "(%s)")))
The first few characters on each line of the search result are used to
show information about some significant tags associated with the
thread.
With [1: 16b2db09] we lost the (undocumented) option to use no Fcc
header only for From addresses matching a regexp. This brings back
that feature and documents it.
1: 2021-01-15 16b2db0986
emacs: various cosmetic improvements
This avoids some ugly error messages and exceptions, and hopes that
some gnus method will display message/rfc822 parts that have only a
file, no :content part.
This is just a regular character in docstrings (as it is fairly often
used in lisp identifiers and buffer names) but is the start of
emphasis in rst. This change is needed to quell a noisy warning when
including notmuch-tree.rsti
This is a bit of a cheat, since the format does not actually
change. On the other hand it is fairly common to do something like
this to shared libary SONAMEs when the ABI changes in some subtle way.
It does rely on the format-version argument being early enough on the
command line to generate a sensible error message.
This new command for notmuch-tree-mode is analogous to
notmuch-search-filter-by-tag, bound to "t" in notmuch-search-mode; it
gets therefore the same "t" keybinding in notmuch-tree-mode (replacing
the current assignment to notmuch-search-by-tag).
The intent of the 'notmuch-jump-key' face is to allow users/themes to
differentiate the text of the minibuffer prompt from the keys that are
associated with jump actions. Commit 5cc106b0 correctly introduced the
'notmuch-jump-key' face for keys, but mistakenly applied it to the
prompt as well.
When mm-text-html-renderer is set to 'w3m, the variable playing the
role of a regular expression for blocked images is
w3m-ignored-image-url-regexp. We bind it when the renderer is not
'shr.
When moving between message in a tree or show buffer, the message at
point is marked as read. Likewise when creating such a buffer, then
the message that is initially at point is supposed to be marked as
read as well.
The latter worked for `notmuch-show' but not for `notmuch-tree'.
Press "RET" or "M-RET" in a search buffer to observe these behaviors.
In both cases the marking is supposed to be done by the function
`notmuch-show-command-hook'. In the case of `notmuch-show' that
function is added directly to `post-command-hook'.
`notmuch-tree' instead adds the function `notmuch-tree-command-hook'
to `post-command-hook' and that calls `notmuch-show-command-hook',
in the respective show buffer, but of course only if that exists.
Because the tree buffer is created asynchronously, the show buffer
doesn't exist yet by the time the `post-command-hook' is run, so
we have to explicitly run `notmuch-tree-command-hook' once the
show buffer exists.
The show buffer is created when `notmuch-tree-goto-and-insert-msg'
calls `notmuch-tree-show-message-in'. `notmuch-tree-process-filter'
is what finally brings us here.
This is more efficient than notmuch-show-only-matching-messages, since
we do not parse the potentially large thread structure to find a
single message.
This is only a partial fix for notmuch-tree view, because displaying
the thread structure in the tree-mode window still crashes on long
threads. It is however enough to make unthreaded view handle long
threads.
This dynamically bound variable can be set when the caller of
notmuch-show guarantees that exactly one message will match the
query. It avoids transporting and parsing the complete thread
structure.
All three of C-c C-c, <menu-bar> <Message> <Send Message>,
and <tool-bar> <Send Message> are bound to message-send-and-exit by
message.el, but notmuch-mua.el only had an explicit override for the
keyboard binding. This mostly manifests as confusing Fcc behaviour for
GUI users.
Patching the bindings for specific keys is rather brittle, since it has
to be aware of every relevant binding. This change switches to instead
using a remap binding, which turns any binding for message-send or
message-send-and-exit into a binding for the corresponding notmuch-mua
command.
The minibuffer-prompt face that was used before made it impossible to
differentiate between two distinct UI elements: (i) the prompt's text
which itself cannot be acted upon, (ii) the actionable keys used to
jump to searches/tags.
The use of a named face, notmuch-jump-key, makes it possible for users
or theme developers to apply properties that are specific to each of
those two cases.
In the interest of backward compatibility, the new face inherits from
minibuffer-prompt.
Most concrete verification steps are likely only taken on the e-mail
address in the first place, and e-mail addresses render more
intelligibly than arbitrary User IDs in the first place.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Amended-by: db, apply dme restructuring suggestions.
Although the function dates from 2015, the autoload is newer. In
particular [1] it is not found in Emacs 25.3.
[1]: id:874ke85tqx.fsf@cgc-instruments.com
Gmane web interface is long gone, remove it. Make MARC the new
default. Update LKML to Lore, where it already redirects anyway. Also
add Notmuch web archive.
- declare-function notmuch-unthreaded lacked file name
- declare-function notmuch-search had differently named last arg
- note: check-declare-directory did not complain about that
- declare-function notmuch-search-show-thread without nil
- some functions declared to be in different file than those
existed ("notmuch" -> "notmuch-lib")
- some related function/declare lines were (/are now) wider than
80-columns; added line breaks (and proper indentation) there
After some discussion [1], I decided it is better to make notmuch users
who rely on this behaviour customize mail-user-agent. This is
consistent with the behaviour of other emacs mail packages.
[1]: id:87k0nuhfrk.fsf@toryanderson.com
notmuch-before-tag-hook and notmuch-after-tag-hook are supposed to
have access to two dynamic variables, tag-changes and query, but these
were lost with the switch to lexical binding in fc4cda07 (emacs: use
lexical-bindings in all libraries, 2021-01-13).
Add a variant of Emacs's dlet (not available until Emacs 28) and use
it in notmuch-tag to expose tag-changes and query to the hooks.
When prompting for one or more tags to add or remove to/from one or
more threads, ensure that the set of tags offered for completion
contains no duplicates.
Some completion packages (e.g. selectrum) will include every member of
the offered list, resulting in the same tag being indicated as a
possibility several times.
The output of "notmuch show --format=sexp --format-version=4"
may contain `:content-type' entries with `nil' as the value,
when it fails to detect the correct value. Account for that
in a few places where we would otherwise risk a type error.
Note that `string=' does not choke on `nil' because it uses
the `symbol-name' when encountering a symbol.
Users may type some text into the buffer on an address line, before
actually invoking address completion. We now use that text as the
initial input when we begin address completion.
Previously we did knowingly replace the actual initial input with some
completion candidate that happens to match. Which candidate is used is
essentially random, at least when the actual initial input is short.
As a result users very often had to begin completion by deleting the
less than helpful "initial input".
IMO Notmuch should not override the default completion mechanism by
default, at least not globally. But since users are already used to
this behavior it is probably too late to change it. Do the next best
thing and at least allow users to opt out.
When called from code, then this function returns non-nil when the
message at point is a matched message. However it does nothing at all
to present that information to the user when it called interactively.
It is therefore safe to conclude that nobody is using this as a
command.
Like `cl-lib' and `pcase', which are already available in all
libraries, `subr-x' also provided many useful functions that
we would like to use.
Making `subr-x' available in every library from the get-go means
that we can use the functions it defines without having to double
check every single time, whether the feature is already available
in the current library.
We need to load `cl-lib' at run-time because we use more from it than
just macros. Never-the-less many, but not all libraries required it
only at compile-time, which we got away with because at least some
libraries already required it at run-time as well.
We use `cl-lib' and (currently to a lesser extend) `pcase' throughout
the code-base, which means that we should require these features in
most libraries.
In the past we tried to only require these features in just the
libraries that actually need them, without fully succeeding. We did
not succeed in doing so because that means we would have to check
every time that we use a function from these features whether they
are already being required in the current library.
An alternative would be to add the `require' forms at the top of every
library but that is a bit annoying too.
In order to make sure that these features are loaded when needed but
also to keep the noise down we only require them in "notmuch-lib.el",
which most other libraries require, and in most of the few libraries
that do not do so, namely "notmuch-draft.el", "notmuch-message.el" and
"notmuch-parser.el". ("coolj.el", "make-deps.el", various generated
libraries, and "notmuch-compat.el" are left touched.)
To some extend this is a personal preference, but the preference is
strongly dependent on whether one is used to a language that makes it
necessary to use variables like this.
This makes it perfectly clear that we are first getting and then using
a "foo":
(use-foo (get-foo))
Sure this has to be read "inside out", but that's something one better
gets used to quickly when dealing with lisp. I don't understand why
one would want to write this instead:
(let ((the-foo (get-foo)))
(use-foo the-foo))
Both `get-foo' and `use-foo' are named in a way that make it very
clear that we are dealing with a "foo". Storing the value in an
additional variable `the-foo' does not make this any more clear.
On the contrary I makes the reader wonder why the author choose to
use a variable. Is the value used more than once? Is the value
being retrieved in one context and then used in another (e.g. when
the current buffer changes)?
No longer use the function `notmuch-search-get-query', which does
nothing but return the value of that variable. That function was
added in [1: f47eeac0] for use in `notmuch-read-query' along-side
related `notmuch-show-get-query' and `notmuch-tree-get-query' but
using it here makes little sense.
1: f47eeac0b0
emacs: set default in notmuch-read-query
Define these variables as automatically buffer-local, meaning that
they always become buffer-local when set unless explicitly told
otherwise using `setq-default' or when using the Custom interface.
Previously they were declared, which keeps the byte-compiler quiet but
is not actually the same as being defined. `notmuch-search-mode' then
made them buffer-local in the current buffer and then set the local
values. This works but is not kosher.
The definitions of the three non-option variables have to be moved up
a bit to enable the change in the next commit, which see.
