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.
We shouldn't force `ido-completion-read' on users who do not otherwise
use Ido. Unfortunately simply turning on `ido-mode' does not change
every `completing-read' into a `ido-completing-read', instead it only
changes file and buffer completion.
I do realize that existing Ido users will initially dislike this
change, but I would like to encourage them to see this as an
opportunity to learn about Fido.
Unlike `ido-mode', build-in `fido-mode' confirms to the standard
completion API, so turning it on causes every `completing-read' to
use the Fido completion mechanism and which is similar to the Ido
mechanism:
> An enhanced `icomplete-mode' that emulates `ido-mode'. This global
> minor mode makes minibuffer completion behave more like `ido-mode'
> than regular `icomplete-mode'."
`notmuch-show-insert-part-text/plain' calls
`notmuch-show-insert-text/plain-hook' with two arguments
MSG and DEPTH. Currently all hook functions ignore MSG but
third-party functions may not. One hook function uses DEPTH.
This function had a few issues.
- Neither its name nor the old comment before it is called made it
clear what it does.
- It took one argument but didn't do anything with it.
- It's doc-string made a few claims, which are untrue and generally
focused on details instead of that its purpose is.
The previous commit switched to lexical-binding but without dealing
with the new warnings about unused lexical arguments and variables.
This commit deals with most of them, in most cases by either removing
leftover bindings that are actually unnecessary, or by marking certain
arguments as "known to be unused" by prefixing their names with "_".
In the case of the functions named `notmuch-show-insert-...' the
amount of silencing that is required is a bit extreme and we might
want to investigate if there is a better way.
In the case of `notmuch-mua-mail', ignoring CONTINUE means that we do
not fully follow the intended behavior described in `compose-mail's
doc-string.
Doing so causes many new compile warnings. Some of these warnings
concern genuine changes in behavior that have to be addressed right
away.
Many other warnings are due to unused variables. Nothing has changed
here, except that the byte-compiler can now detect these pre-existing
and harmless issues. We delay addressing these issues so that we can
focus on the important ones here.
A third group of warnings concern arguments that are not actually used
inside the function but which cannot be removed because the functions
signature is dictated by some outside convention. Silencing these
warning is also delayed until subsequent commits.
`outline-minor-mode' treats comments that begin with three or more
semicolons as headings. That makes it very convenient to navigate
code and to show/hide parts of a file.
Elips libraries typically have four top-level sections, e.g.:
;;; notmuch.el --- run notmuch within emacs...
;;; Commentary:...
;;; Code:...
;;; notmuch.el ends here
In this package many libraries lack a "Commentary:" section, which is
not optimal but okay for most libraries, except major entry points.
Depending on how one chooses to look at it, the "... ends here" line
is not really a heading that begins a section, because it should never
have a "section" body (after all it marks eof).
If the file is rather short, then I left "Code:" as the only section
that contains code. Otherwise I split the file into multiple sibling
sections. The "Code:" section continues to contain `require' and
`declare-function' forms and other such "front matter".
If and only if I have split the code into multiple sections anyway,
then I also added an additional section named just "_" before the
`provide' form and shortly before the "...end here" line. This
section could also be called "Back matter", but I feel it would be
distracting to be that explicit about it. (The IMO unnecessary but
unfortunately still obligatory "... ends here" line is already
distracting enough as far as I am concerned.)
Before this commit some libraries already uses section headings, some
of them consistently. When a library already had some headings, then
this commit often sticks to that style, even at the cost inconsistent
styling across all libraries.
A very limited number of variable and function definitions have to be
moved around because they would otherwise end up in sections they do
not belong into.
Sections, including but not limited to their heading, can and should
be further improved in the future.
In practice this probably does not make a difference or we would
have heard about it many times, but better be safe than sorry.
Process sentinels are called not only when the process has finished
but also on other state changes.
When running "notmuch" we use its full path but when displaying the
command to the user we show just its name for readability reasons.
Avoid passing around both representations because it is very easy
to get the name from the path.
Notmuch itself uses the involved functions just for "notmuch" but
there might be extensions that use them for other executable so we
forgo other potential simplifications.
The buffer of the error process is accessible using `process-buffer'.
We still have to store the error-buffer in the non-error process
because for that process `process-buffer' obviously returns its own
buffer.
We no longer support Emacs releases before version 25.1.
Also adjust the sentinels which only had to deal with
an error file when using an older Emacs release was used.
These functions are used as action/notify functions. That dictates
the appropriate function signatures but even though these functions
are not used for anything else they use incompatible signatures,
forcing the callers to use lambda expressions to deal with these
incompatibilities.
Fix that by adjusting the function signatures to the needs of the
only intended callers.
Two of these functions were defined as commands but because the
interactive form did not return the mandatory arguments, we know
that nobody (successfully) used these as commands.
In one case we move the location of a y-or-n-p prompt.
This reverts commit f9fbd1ee3b.
Emacs provides a mechanism for avoiding wiping out buffer-local
variables: marking them as "permanent local", which essentially
means "don't wip out the local value when enabling major-mode".
(put 'the-variable 'permanent-local t)
See (info "(elisp)Creating Buffer-Local").
Whether refreshing the buffer contents should involve re-enable the
mode is a different question, which should not be decided based on
the fact that we want keep the value of some random variable, not
least because some other (e.g. cache) variables are likely expected
to be wiped.
One should never bind unnamed commands in keymaps because doing that
makes it needlessly hard for users to change these bindings.
Replace such anonymous bindings with named commands that are generated
using macros and some boilerplate. Using macros is better than using a
simple loop because that makes it possible for `find-function' to find
the definitions. Eat your boilerplate--it forms character.
Admittedly this approach is quite ugly and it might be better to teach
the original commands to support different buffers directly instead of
requiring wrapper commands to do just that.
Never-the-less as a short-term solution this is better than what we
had before.
Inline a simplified version of `notmuch-documentation-first-line'
into its only caller. The new code snippet differs from the
removed function in that it returns nil instead of the empty string
for symbols that have no function documentation. That value is
ultimately used as an argument to `concat', which treats nil like
the empty string. So we can do the logical thing without changing
the behavior.
Since [1: f8bdba37] no key is bound to this command and it is
redundant because the behavior of `push-command' is identical
when called as a command.
1: f8bdba37d3
emacs: tree: remove binding for pressing button in message pane
We could just have switched to using `cl-remove-if-not' instead,
but the two uses of the *remove-if-not function are pretty strange
to begin with so we refactor to not use any such function at all.
The first sentence should fit on the first line. It is okay if
the first sentence/line does not contain all the information that
the rest of the doc-string covers.
Previously it was defined in "notmuch-hello.el" and its name contained
"hello" solely because it replaced an anonymous function that was
mistakenly only bound in `notmuch-hello-mode-map'. But it makes more
sense to bind it in all notmuch modes and even if we did not change
that aspect it still would make no sense to have "hello" in its name.
Notmuch requires at least version 25 of Emacs now.
Adjust comments that previously referenced version 24 specifically,
even though they also apply to later releases. Remove documentation
and code that no longer applies.
- `mm-shr' no longer references `gnus-inhibit-images'.
This fixes a regression introduced in [1: 7e20d264]. If the argument
RETURN-ACTION was non-nil then we should pass along the value of that
argument. Instead we passed along the constant symbol `return-action'.
1: 7e20d26480
emacs: Fix mail composition under Emacs 23
Key bindings should not be defined at the top-level but inside
a `defvar' form. Doing it at the top-level makes it harder to
reliably customize key bindings.
With text-quoting-style 'grave keeps "'" and "`" quotes unaltered
for further processing done by this code (regardless of locale...).
The tools that read the reStructuredText markup generated can do
their styling instead.
Added temporary conversions of ' and ` to \001 and \002 so that
's and `s outside of `...' and `...` are converted separately
('s restored back to ' and `s converted to \`).
Both `...' and `...` are finally "converted" to `...` (not ``...``).
https://docutils.sourceforge.io/docs/user/rst/quickref.html documents
that as `interpreted text`:
"The rendering and meaning of interpreted text is domain- or
application-dependent. It can be used for things like index
entries or explicit descriptive markup (like program identifiers)."
Which looks pretty much right.
Currently `message-send-hook` functions are being called twice: In
notmuch send common when `notmuch-mua-send-hook` functions are
run (which by default includes `notmuch-mua-message-send-hook`) and in
`message-send` itself.
Because `message-send-hook` functions are run in `message-send` itself,
we don't need also need to run them before we delegate to `message-send`
Calling `notmuch-mua-message-send-hook` resulted in functions in
`message-send-hook` to be called twice. This causes bugs in
non-idempotent hook functions.
Emacs face definition forms are either
((DISPLAY . PLIST)
(DISPLAY . PLIST))
or
((DISPLAY PLIST) ;For backward compatibility.
(DISPLAY PLIST))
Commit a2388bc56e (2020-08-08) follows
neither of the correct formats. It defines:
`((((class color) (background light))
,@(and (>= emacs-major-version 27) '(:extend t))
(:background "#f0f0f0"))
(((class color) (background dark))
,@(and (>= emacs-major-version 27) '(:extend t))
(:background "#303030")))
which produces:
((DISPLAY
:extend t (:background "#f0f0f0"))
(DISPLAY
:extend t (:background "#303030")))
And that is wrong format.
This change fixes the face definition form to produce:
((DISPLAY
:extend t :background "#f0f0f0")
(DISPLAY
:extend t :background "#303030"))
which follows the (DISPLAY . PLIST) format (see above).
This means that notmuch commands obey display-buffer-alist so the user
can customize how buffers show up.
It also permits the use of C-x 4 4, C-x 5 5 and C-x t t, available in
Emacs 28. For example, one can use C-x 4 4 M-x notmuch-jump-search RET
to open a saved search in another window rather than the current window.
Or in notmuch-search mode, C-x 5 5 RET to view the message at point in
a new frame.
notmuch-tree has custom buffer display logic, so bind
display-buffer-overriding-action to make pop-to-buffer-same-window
behave exactly as switch-to-buffer while that function is running.
Now that notmuch-tree-next-thread acts more like its notmuch-show
counterpart, let's update the binding to move to the next thread after
archiving.
Signed-off-by: William Casarin <jb55@jb55.com>
This introduces a new function called
notmuch-tree-next-thread-from-search which is analogous to
notmuch-show-next-thread. It will switch to the next or previous
thread from the parent search results.
We rename notmuch-tree-{prev,next}-thread to a more descriptive
notmuch-tree-{prev,next}-thread-in-tree to reflect the fact that it
only moves to the next thread in the current tree.
notmuch-tree-next-thread now switches to the next thread in the
current tree first, but if there are none, it looks for the next tree
in the search results.
This makes notmuch-tree feel more like notmuch-show when using the
M-Enter, M-n and M-p bindings.
Signed-off-by: William Casarin <jb55@jb55.com>
This variable will be used in a similar fashion to
notmuch-show-parent-buffer. It will be used to navigate between
threads from the parent search buffer.
Signed-off-by: William Casarin <jb55@jb55.com>
Previously in message-show mode message's first header line (From
header) was always indented, even if user had turned thread
indentation off with "<" (notmuch-show-toggle-thread-indentation)
command.
This change modifies notmuch-show-insert-headerline function so that
it doesn't indent the first header line if notmuch-show-indent-content
variable is nil.
This change also modifies tests so that they expect this new output
format:
test/emacs-show.expected-output/notmuch-show-indent-thread-content-off
