[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: > > [Note it is possible to (mis)configure a terminal so that this does not > work -- eg by setting backspace to do C-h -- but the standard C-? > should be fine.] This seems acceptable to me, but I'm curious what more serious emacs-in-terminal

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

David Bremner writes: > Mark Walters writes: > >> 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. >> > > series

Re: "id buttonization" test failure

David Bremner writes: > > > The following "fixes" this test failure. This suggests to me something > that only fails when notmuch-show-buttonise-links is called from the C > redisplay code, and not when it's called from lisp. The last paragraph of

Re: Status of Vim client

Lewis wrote: > I'm also aware of two Vim clients on GitHub: > > * https://github.com/felipec/notmuch-vim (last commit: 2014-05-22) > > * https://github.com/imain/notmuch-vim (last commit: 2015-08-24) > > So, are the clients really stable, or are they rotting because nobody > uses them? My hope

Re: [PATCH] Test: emacs forwarding

Mark Walters writes: > There are no tests for forwarding messages inside emacs, so add > some. Also, there is a bug in the forward multiple messages code in > the case that only occurs when the user has changed > message-forward-before-signature to nil -- the messages

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

Mark Walters writes: > 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. > series pushed, d

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

Mark Walters writes: > The current code for address completion takes the list of possible > completions (whether generated internally or externally), makes the > first match the initial value for the completion, and puts all the > others (but not the first match) into

Re: [PATCH] emacs: add mimetype completions to searches

Mark Walters writes: pushed d ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch

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

On Sun, Oct 09 2016, Ioan-Adrian Ratiu wrote: > 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

[PATCH] test/test-lib.sh: execute basename(1)s lazier in test_expect_equal_file ()

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. ---

[PATCH v5 1/7] emacs: tree: make refresh use generic binding

Not using the generic binding is an anomaly from when tree was in contrib (as pick). --- emacs/notmuch-tree.el | 1 - 1 file changed, 1 deletion(-) diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el index 1555812..d5587a9 100644 --- a/emacs/notmuch-tree.el +++ b/emacs/notmuch-tree.el @@

[PATCH v5 5/7] emacs: notmuch-search-refresh-view: reuse buffer

From: Ioan-Adrian Ratiu 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

[PATCH] test/T000-basic: replaced use of which(1) with shell builtin command -v

Some minimal chroot/container environments don't have which(1) installed. --- test/T000-basic.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/T000-basic.sh b/test/T000-basic.sh index d6811bd10756..0a8d6cdf40fc 100755 --- a/test/T000-basic.sh +++ b/test/T000-basic.sh @@

[PATCH v5 0/7] Add refresh all buffers functionality

This is a simplified version of the series at id:20161008210139.25322-1-...@adirat.com The main change is that it makes all the refresh functions refresh the buffer without forcing the buffer to be displayed. In tree and show mode this was already the case; in search mode it is a change but

[PATCH v5 3/7] emacs: hello: stop update from forcing the buffer to be displayed

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

[PATCH v5 2/7] emacs: make the refresh functions more consistent

The different refreshed functions were called differently: some were called interactively and some were not. Make them all interactive. --- emacs/notmuch-hello.el | 1 + emacs/notmuch-lib.el | 9 - emacs/notmuch.el | 1 + 3 files changed, 6 insertions(+), 5 deletions(-) diff

Re: [PATCH v5 2/7] emacs: make the refresh functions more consistent

On Sun, Oct 09 2016, Mark Walters wrote: > The different refreshed functions were called differently: some were > called interactively and some were not. Make them all interactive. > --- > emacs/notmuch-hello.el | 1 + > emacs/notmuch-lib.el | 9 - >

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

On Sun, 09 Oct 2016, David Bremner wrote: > 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