Re: [PATCH] emacs: tag-jump: make k binding for the reverse tag change map

Mark Walters writes: > Currently, by default k invokes the tag-jump menu, and following it by > r invokes the reverse tag change jump menu. This is awkward to type > (e.g. k r u for undoing a -unread change). This changes it so that k > followed by k invokes the

Re: [PATCH 2/2] emacs: mua: check for misplaced secure mml tags

Mark Walters writes: > + (save-excursion > +(let ((body-start (progn (message-goto-body) (point > + (goto-char (point-max)) > + ;; We are always fine if there is no secure tag. > + (when (search-backward "<#secure" nil 't) > + ;; There is a

feature request: highlighting of partial jump sequences

I (very) recently started using longer key sequences with Mark's tag-jump feature. One thing I miss from a similar feature in org-mode (e.g. exporting) is some visual feedback on what I have typed so far, and thus what my next key is likely to do. d

[PATCH v4 1/2] emacs: mua: extract a common message-send function.

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. --- emacs/notmuch-mua.el | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git

[PATCH v4 0/2] Check for misplaced secure mml tags

This is a new version of id:1475417131-24915-1-git-send-email-markwalters1...@gmail.com It fixes bremner's comment that the warning message presented to the user was wrong. Also, I think the logic is a little simpler, and I think the general layout extends to any other checks we wish to do

[PATCH v4 2/2] emacs: mua: check for misplaced secure mml tags

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

[PATCH v4 3/6] emacs: notmuch-search: add no-display functionality

If no-display is non-nil when updating a notmuch-search buffer, do not force bring to foreground in a window said search results buffer. Signed-off-by: Ioan-Adrian Ratiu --- emacs/notmuch.el | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git

[PATCH v4 4/6] emacs: notmuch-show: refresh all windows displaying buffer

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

[PATCH v4 5/6] emacs: add no-display arg to generic refresh functions

As stated in the documentation for notmuch-buffer-refresh-function, each buffer major mode's refresh function takes two args, but notmuch-refresh-this-buffer and notmuch-poll-and-refresh-this-buffer only pass the first arg. Add the second arg because it's very useful for background refreshing.

[PATCH v4 2/6] emacs: notmuch-search-refresh-view: reuse buffer

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

Re: [PATCH v4 2/2] emacs: mua: check for misplaced secure mml tags

Mark Walters writes: > > 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. Is this paragraph leftover from when this series was one patch? If so, I can amend it

Re: [PATCH v4 2/2] emacs: mua: check for misplaced secure mml tags

On Sat, 08 Oct 2016, David Bremner wrote: > Mark Walters writes: >> >> 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. > > Is this

[PATCH v4 1/6] emacs: make the refresh code more consistent

From: Mark Walters The current refresh code is a little haphazard with some of the refresh functions called interactively, and some not. Some of the refresh functions take arguments and they aren't consistent. This makes all the functions have the same form. ---

[PATCH v4 6/6] emacs: notmuch-lib: add refresh all buffers function

notmuch-refresh-all-buffers calls each buffer's major mode specific refresh function using the generic notmuch-refresh-this-buffer function. Each buffer-specific refresh function has the same form, taking a prefix and a no-display arg. Passing the no-display arg is very useful because it tells

[PATCH v4 0/6] Add refresh all buffers functionality

Changes since v3: This is a complete rewrite based on Mark's awesome patch to make all buffer mode's refresh functions non-interactive and consistent wrt to their arguments (Mark's patch is included in this series). For a complete example how I use this feature you can look at

Re: [PATCH] emacs: include first match in address completion

Mark Walters writes: > This tries to get round most of these problems by including the full > list of possible completions, but with the first match moved to the > very end of the list. Have you thought about how this should be adjusted when the completion entries are

[PATCH] emacs: jump: make multilevel keys do multilevel jump

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.

Re: [PATCH] emacs: jump: make multilevel keys do multilevel jump

Mark Walters writes: > 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,

Re: "id buttonization" test failure

David Bremner writes: > 2) I can interactively duplicate a similar, but not identical, bug as >follows. > >- add the attached message (extracted from the test suite) to my mail > store >- open it notmuch-show (emacs 25.1, gtk/GUI) >- go to the last line