Provide functionality to resume editing a message previously saved with
notmuch-draft-save, including decoding the X-Notmuch-Emacs-Secure
header.
Resume gets the raw file from notmuch and using the emacs function
mime-to-mml reconstructs the message (including attachments).
'e' is bound to resume a draft from show or tree mode.
This provides initial support for postponing in the emacs frontend;
resuming will follow in a later commit. On saving/postponing it uses
notmuch insert to put the message in the notmuch database
Current bindings are C-x C-s to save a draft, C-c C-p to postpone a
draft (save and exit compose buffer).
Previous drafts get tagged deleted on subsequent saves, or on the
message being sent.
Each draft gets its own message-id, and we use the namespace
draft-.... for draft message ids (so, at least for most people, drafts
are easily distinguisable).
We want to use "e" for editting postponed messages in show, and in
tree view, so remove the binding for the function which does
(In message pane) Activate BUTTON or button at point
This hook can be used to update the message based on the results of
address completion. For example using message-templ or gnus-alias to set
the From address based on the To address just completed.
The post-completion command is added to the notmuch-company backend to
ensure that the hook is also called company completion is started
without going through notmuch-address-expand-name. See the docstring of
`company-backends' for more information.
This makes replying to a message in tree view, use the decrypted state
from the message pane if it is open. Previously it just used the
global decryption state from notmuch-crypto-process-mime.
In particular if notmuch-crypto-process-mime is nil, and the user
views the messages (which doesn't decrypt), toggles decryption in the
message pane, and then replies, the reply will be decrypted.
This makes $ in the tree pane toggle decryption in the message
pane. Without this the user can only decrypt the message pane by
switching to it, or by setting decryption on globally by setting
notmuch-crypto-process-mime to t.
Add support for composing an email in the Notmuch Emacs UI using a
mailto: URL. The mailto: URL mode is mutually exclusive with
specifying other message modifying parameters and positional
arguments.
The notmuch-tag-flagged, notmuch-search-flagged-face and
notmuch-crypto-part-header faces defaulted to "blue", which is nearly
unreadable when a dark background is in use. This is addressed by using
"LightBlue1" for dark backgrounds.
As a side effect, these faces are now no-op definitions for grayscale or
mono displays.
If the given subcommand is not known to notmuch, try to execute
external notmuch-<subcommand> instead. This allows users to have their
own notmuch related tools be run via the notmuch command, not unlike
git does. Also notmuch-emacs-mua will be executable via 'notmuch
emacs-mua'.
By design, this does not allow notmuch's own subcommands to be
overriden using external commands.
The normal tag commands in search mode tag the all threads meeting the
region when called interactively. This makes them do the same when
called non-interactively. This is a change in the api.
Moved the 2 basename(1) executions to the test failure branch in
test_expect_equal_file ().
The output of basename(1) executions in function test_expect_equal_file ()
are only used when tests fails -- when all tests pass these 2 basename(1)
executions are no longer done at all.
This makes tag changes appear in the message pane as well as in the
tree window.
Note that the message pane is reloaded each time a message is viewed
so the tags shown in the message pane can still be different from
those in the tree window. Usually this will just be that the tag
change is still shown as a change (strikethough underline etc) in the
tree window, and are shown after the change in the message
pane. However, if something else updates the database then the tags
shown can be genuinely different.
The command notmuch-interesting-buffer has got out of date -- it
doesn't mention notmuch-tree, and it still refers to message-mode not
notmuch-message-mode. Update both of these.
This fixes the bug that notmuch-cycle-notmuch-buffers does not include
notmuch-tree or notmuch-message-mode buffers in its cycling.
This adds a file under devel listing all the keybindings sorted by key
in the main three modes (search, show and tree).
To reduce clutter it only lists the single key "unmodified"
keybindings: I think all our uses of prefixes and modifiers are
natural variants of the unmodified binding (eg M-n compared to n in
show mode)
This should make easier to see what keybindings are available when
adding new features.
notmuch-show--build-buffer now queries a list of queries built by the
former. This simplifies the logic. It also provides an easy place to
experiment with alternate sets of queries for given notmuch-show-*
variables (e.g. users can use advice-add to do so in a surgical way).
This commit expands docstrings for notmuch-fcc-dirs and
notmuch-maildir-fcc-with-notmuch-insert to describe how quoted strings
are processed and make the ability to configure sent folders containing
whitespace more discoverable.
In commit 2a7b11b064 the default value
for notmuch-search-line-faces was changed so that it didn't match the
specification in the corresponding defcustom. This meant that it was
difficult for the user to customize this variable as they got a type
mismatch error.
Note anyone who had already customised this variable would not see
this bug as their customisation would match the defcustom.
We can't use c-u = as some of the notmuch-show refresh function
already uses that. This is a global keybinding for a relatively
infrequent function but M-= seems unlikely to cause conflicts.
notmuch-refresh-all-buffers calls each buffer's major mode specific
refresh function using the generic notmuch-refresh-this-buffer function.
Since the earlier changesets have stopped the refresh functions from
forcing the buffers to be redisplayed this can refresh buffers that
are not currently displayed without disturbing the user. This is very
useful for silent async background updating the emacs display when new
mail is fetched.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
This updates all windows displaying a notmuch-show buffer when the
buffer refresh function is called.
Each window displaying a notmuch-show buffer has its own currently
displayed message based on the (point) location. We store the state
of all displayed windows when refreshing a notmuch-show buffer and
re-apply the current shown message (point) for all windows.
Implementation note: Each window has it's own (point) value, besides
the buffer's (point) value. Sometimes these values are identical like
in the case where a single window displays a buffer. When multiple
windows display a buffer, (point) returns each window's specific value.
What we are storing in this changeset is the window values not the
buffer point values. The buffer's point is returned only if no window
is displaying the buffer, a case we do not care about here.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
There's no reason to completely kill a buffer while refreshing its
search results because the buffer name is constant between refreshes
(based on the search query), only its contents may change and notmuch
search kills all local variables, so it's safe to reuse.
Reusing the same buffer also makes it possible to do things like
refreshing a buffer which is not focused or even not shown in any
window - this will be used in the next commits to add auto-refresh
capabilities to all existing notmuch buffers + a function to call
after syncing mail to refresh everything.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
If no-display is non-nil when calling notmuch-search then do not force
the search buffer to be displayed.
Signed-off-by: Ioan-Adrian Ratiu <adi@adirat.com>
Make the notmuch-hello refresh function (notmuch-hello-update) not
force the buffer to be displayed. All the callers call it when the
buffer is already displayed so it will only affect non-interactive
callers. Since it is just a trivial wrapper of notmuch-hello anyone
who wants to force the buffer to be displayed should just call
notmuch-hello.
If an encrypted multipart message is received which contains html and
notmuch-multipart/alternative-discouraged is set to discourage "text/plain",
any encrypted parts are not decrypted during generation of the reply
text. This fixes that problem by making sure notmuch-mua-reply does
that.
notmuch jump allows the user to specify a key sequence rather than
just a single key for its bindings. However, it doesn't show what has
already been typed so it can be difficult to see what has
happened. This makes each key press appear, and the jump menu reduce
to the possible follow up keys.
We also bind backspace (emacs symbol DEL) to go back up a level in the
subjumpmaps, and to exit from the top level.
In commit 297d091e1c the key for
switching to the reverse keymap was changed from r to k but the
docstring for the defcustom was not updated. This changeset updates
the documentation to match.
Thanks to Lucas (id:147263183913.27784.12274024193186585889@mbp) for the
bug report and the test case.
I decided to use the python version because the python bindings could
use more exercise.
This seems to fix a problem with emacs 25 creating partial buttons by
calling n-s-b-l with a region that does not include the whole button.
I'm not 100% sure it's legit to act outside the region passed by
jit-lock, but goto-address-fontify-region (where I borrowed the code
from) already does this, so this patch to not make things worse.
Emacs message-send seems to ignore a secure mml tag anywhere except at
the start of the body, and it must be followed by a newline. Since
this is almost certainly not desired we check for it, and require user
confirmation before sending.
As the setup before message-send or message-send-and-exit is getting
more complicated it is convenient to unify the two correspoinding
notmuch functions.
This commit adds a common message-send function for message-send and
message-send-and-exit. At the moment the overlap is small, but the
message-send function will get more complex.
