* [PATCH] emacs: include first match in address completion
@ 2016-09-27 15:45 Mark Walters
2016-10-08 23:26 ` David Bremner
2016-10-09 12:08 ` David Bremner
0 siblings, 2 replies; 4+ messages in thread
From: Mark Walters @ 2016-09-27 15:45 UTC (permalink / raw)
To: notmuch
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 the possible completions.
This has the nice effect that the <down> key takes you immediately to
the next completion (whereas if the first match were included in the
possible completions it would take you to the first match
again).
However, it has two side effects. First, once you have completed to
the full match you find it says and try completing again you get told
"no match" not "sole completion". Secondly, if you delete some of the
text and try completing you don't get the first match as an option.
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.
---
Jani found this bug/odd behaviour on irc: it shows up particularly
when resending/bouncing a message as we don't have a company mode
option for that yet. It seems that the bahaviour dates back to the
first introduction of address completion in 2010. I don't think this
there is a perfect solution but this seems like an improvement.
Best wishes
Mark
emacs/notmuch-address.el | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
index 10eaab1..b2e1fba 100644
--- a/emacs/notmuch-address.el
+++ b/emacs/notmuch-address.el
@@ -194,7 +194,14 @@ external commands."
(t
(funcall notmuch-address-selection-function
(format "Address (%s matches): " num-options)
- (cdr options) (car options))))))
+ ;; We put the first match as the initial
+ ;; input; we put all the matches as
+ ;; possible completions, moving the
+ ;; first match to the end of the list
+ ;; makes cursor up/down in the list work
+ ;; better.
+ (append (cdr options) (list (car options)))
+ (car options))))))
(if chosen
(progn
(push chosen notmuch-address-history)
--
2.1.4
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] emacs: include first match in address completion
2016-09-27 15:45 [PATCH] emacs: include first match in address completion Mark Walters
@ 2016-10-08 23:26 ` David Bremner
2016-10-09 10:10 ` Mark Walters
2016-10-09 12:08 ` David Bremner
1 sibling, 1 reply; 4+ messages in thread
From: David Bremner @ 2016-10-08 23:26 UTC (permalink / raw)
To: Mark Walters, notmuch
Mark Walters <markwalters1009@gmail.com> 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 sorted according to some priority? I guess if we treated the
list circularly putting the highest priority at the end of list would be
ok. I don't know if that is feasible.
d
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] emacs: include first match in address completion
2016-10-08 23:26 ` David Bremner
@ 2016-10-09 10:10 ` Mark Walters
0 siblings, 0 replies; 4+ messages in thread
From: Mark Walters @ 2016-10-09 10:10 UTC (permalink / raw)
To: David Bremner, notmuch
On Sun, 09 Oct 2016, David Bremner <david@tethera.net> wrote:
> Mark Walters <markwalters1009@gmail.com> 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 sorted according to some priority? I guess if we treated the
> list circularly putting the highest priority at the end of list would be
> ok. I don't know if that is feasible.
Hi
I hadn't thought about that at all. However, the function
notmuch-address-expand-name just gets a list of possible completions and
from notmuch-address-matching (via notmuch-address-options) and displays
them in the order it receives them. Thus the sorting code goes into
notmuch-address-matching rather than notmuch-address-expand-name, and
hence everything "just works".
This does seem to be the case when I tried on top of my old sort address
patch.
(Note company-mode does its own sort unless not told not to. So at the
moment I think you see an unsorted list of completion candidates if you
are not using company.)
Best wishes
Mark
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] emacs: include first match in address completion
2016-09-27 15:45 [PATCH] emacs: include first match in address completion Mark Walters
2016-10-08 23:26 ` David Bremner
@ 2016-10-09 12:08 ` David Bremner
1 sibling, 0 replies; 4+ messages in thread
From: David Bremner @ 2016-10-09 12:08 UTC (permalink / raw)
To: Mark Walters, notmuch
Mark Walters <markwalters1009@gmail.com> 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 the possible completions.
pushed,
d
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2016-10-09 12:08 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-09-27 15:45 [PATCH] emacs: include first match in address completion Mark Walters
2016-10-08 23:26 ` David Bremner
2016-10-09 10:10 ` Mark Walters
2016-10-09 12:08 ` David Bremner
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).