bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Phil Sainty]

[-- Attachment #1: Type: text/plain, Size: 669 bytes --]

I tried out ecomplete for email address completion today(*),
and I found it slightly annoying that when there was only a
single match for the text, I still have to firstly type M-n
to access the completion 'list', and then RET to select the
only available option.

Would the attached patch be a reasonable enhancement?


-Phil

(*) On account of 
https://www.reddit.com/r/emacs/comments/sl33w6/ecomplete_the_emacs_contact_manager_you_were/



In GNU Emacs 27.2 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll 
bars)
  of 2021-07-12 built on phil-lp
Windowing system distributor 'The X.Org Foundation', version 
11.0.12008000
System Description: Ubuntu 18.04.6 LTS

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ecomplete-auto-select.patch --]
[-- Type: text/x-diff; name=ecomplete-auto-select.patch, Size: 1174 bytes --]

diff --git a/lisp/ecomplete.el b/lisp/ecomplete.el
index 260657e0f7..e011c3210e 100644
--- a/lisp/ecomplete.el
+++ b/lisp/ecomplete.el
@@ -80,6 +80,10 @@ ecomplete-sort-predicate
 		(function-item :tag "Sort by newness" ecomplete-newness)
 		(function :tag "Other")))
 
+(defcustom ecomplete-message-display-abbrev-auto-select t
+  "Whether `message-display-abbrev' should automatically select a sole option."
+  :type 'boolean)
+
 ;;; Internal variables.
 
 (defvar ecomplete-database nil)
@@ -174,6 +178,12 @@ ecomplete-display-matches
 	  (define-key local-map (kbd "<down>") next-func)
 	  (define-key local-map (kbd "M-p") prev-func)
 	  (define-key local-map (kbd "<up>") prev-func)
+          ;; Auto-select when there is only a single option.
+          (when ecomplete-message-display-abbrev-auto-select
+            (save-match-data
+              (when-let ((match (string-match "\\`\\(.+\\)\n" matches)))
+                (when (string= (match-string 0 matches) matches)
+                  (setq selected (match-string 1 matches))))))
 	  (let ((overriding-local-map local-map))
 	    (while (and (null selected)
 			(setq command (read-key-sequence highlight))

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> I tried out ecomplete for email address completion today(*),
> and I found it slightly annoying that when there was only a
> single match for the text, I still have to firstly type M-n
> to access the completion 'list', and then RET to select the
> only available option.
>
> Would the attached patch be a reasonable enhancement?

ecomplete tries to emulate how these things work in major browsers, and
they do not work this way (autoselect when there's only one match) --
because the user may be typing to see what's available, and would then
remove some characters if they don't get the matches they're looking
for.

So if we're adding this, it should default to nil, but I'm a bit
sceptical that many people would want the auto-select behaviour in any
case.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Phil Sainty]

On 2022-02-11 19:30, Lars Ingebrigtsen wrote:
> ecomplete tries to emulate how these things work in major browsers,
> and they do not work this way (autoselect when there's only one
> match) -- because the user may be typing to see what's available,
> and would then remove some characters if they don't get the matches
> they're looking for.

They can still do all of that, just as before.

The "automated" part of my patch happens *after* the user has finished
adding/removing characters, and has explicitly said (via M-n) that they
now wish to choose from one of the visible completion options.

The only difference between the old and new behaviour is that, in cases
where they'd filtered the completion options down to a single option,
they no longer have to additionally (and redundantly) type RET after
M-n to select the only thing that they could possibly select.

("M-n" acts like the sequence "M-n RET", in other words.)


-Phil

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Phil Sainty]

[-- Attachment #1: Type: text/plain, Size: 223 bytes --]

I realised this would be better with some minor refactoring of
the existing code, so I'm attaching a new version of that patch.

I've used "git diff --ignore-space-change" for clarity (hence the
indentation isn't correct).

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: ecomplete-auto-select2.patch --]
[-- Type: text/x-diff; name=ecomplete-auto-select2.patch, Size: 2466 bytes --]

diff --git a/lisp/ecomplete.el b/lisp/ecomplete.el
index 260657e0f7..ad3cf199e7 100644
--- a/lisp/ecomplete.el
+++ b/lisp/ecomplete.el
@@ -149,10 +149,14 @@ ecomplete-get-matches
 (defun ecomplete-display-matches (type word &optional choose)
   "Display the top-rated elements TYPE that match WORD.
 If CHOOSE, allow the user to choose interactively between the
-matches."
+matches.
+
+Auto-select when `ecomplete-message-display-abbrev-auto-select' is
+non-nil and there is only a single completion option available."
   (let* ((matches (ecomplete-get-matches type word))
+         (match-list (and matches (split-string matches "\n")))
+         (max-lines (and matches (- (length match-list) 2)))
          (line 0)
-	 (max-lines (when matches (- (length (split-string matches "\n")) 2)))
          (message-log-max nil)
          command highlight)
     (if (not matches)
@@ -163,25 +167,30 @@ ecomplete-display-matches
 	  (progn
 	    (message "%s" matches)
 	    nil)
-	(setq highlight (ecomplete-highlight-match-line matches line))
+        (if (and ecomplete-message-display-abbrev-auto-select
+                 (eql 0 max-lines))
+            ;; Auto-select when only one option is available.
+            (nth 0 match-list)
+          ;; Interactively choose from the filtered completions.
           (let ((local-map (make-sparse-keymap))
                 (prev-func (lambda () (setq line (max (1- line) 0))))
                 (next-func (lambda () (setq line (min (1+ line) max-lines))))
                 selected)
             (define-key local-map (kbd "RET")
-	    (lambda () (setq selected (nth line (split-string matches "\n")))))
+              (lambda () (setq selected (nth line match-list))))
 	    (define-key local-map (kbd "M-n") next-func)
 	    (define-key local-map (kbd "<down>") next-func)
 	    (define-key local-map (kbd "M-p") prev-func)
 	    (define-key local-map (kbd "<up>") prev-func)
             (let ((overriding-local-map local-map))
+              (setq highlight (ecomplete-highlight-match-line matches line))
               (while (and (null selected)
 			  (setq command (read-key-sequence highlight))
 			  (lookup-key local-map command))
 	        (apply (key-binding command) nil)
 	        (setq highlight (ecomplete-highlight-match-line matches line))))
 	    (message (or selected "Abort"))
-	  selected)))))
+            selected))))))
 
 (defun ecomplete-highlight-match-line (matches line)
   (with-temp-buffer

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> The "automated" part of my patch happens *after* the user has finished
> adding/removing characters, and has explicitly said (via M-n) that they
> now wish to choose from one of the visible completion options.
>
> The only difference between the old and new behaviour is that, in cases
> where they'd filtered the completion options down to a single option,
> they no longer have to additionally (and redundantly) type RET after
> M-n to select the only thing that they could possibly select.
>
> ("M-n" acts like the sequence "M-n RET", in other words.)

Ah, I see.  Well, that's a lot better.  But...  it seems like a lot of
stuff to just not have to hit RET when choosing an email address.  And
it makes the action of `M-n' less predicable -- sometimes it'll choose a
name, and sometimes not.

So I'm still not sure whether this makes sense for Emacs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Phil Sainty]

On 2022-02-12 19:49, Lars Ingebrigtsen wrote:
> Ah, I see.  Well, that's a lot better.  But...  it seems like a lot
> of stuff to just not have to hit RET when choosing an email address.

I thought that it was a small amount of stuff to prevent a noticeable
irritation.

I can see that you don't find the current behaviour to be irritating,
but "why can't I complete a singlular match with a single command?"
was one of my first questions upon trying ecomplete, so I'd be awfully
surprised if I was alone in that.


> And it makes the action of `M-n' less predicable -- sometimes it'll
> choose a name, and sometimes not.

I feel this is mitigated by the fact that the user sees in advance
what it's going to do (based on whether there's one match, or more
than one match, displayed in the echo area at the time).


> So I'm still not sure whether this makes sense for Emacs.

Having it as a user option is appropriate then, I think.  I'm in
favour of enabling the patched behaviour by default, but I don't mind
if it's opt-in.

I probably didn't pick a good name for the option, though.  In
hindsight something like `ecomplete-display-matches-auto-choose' is
probably better.  Or `ecomplete-display-matches-choose-dwim', given
that it's a DWIM-ish behaviour?


-Phil

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> I probably didn't pick a good name for the option, though.  In
> hindsight something like `ecomplete-display-matches-auto-choose' is
> probably better.  Or `ecomplete-display-matches-choose-dwim', given
> that it's a DWIM-ish behaviour?

The latter sounds better to me.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#53935: [External] : bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Drew Adams]

> > I probably didn't pick a good name for the option, though.  In
> > hindsight something like `ecomplete-display-matches-auto-choose' is
> > probably better.  Or `ecomplete-display-matches-choose-dwim', given
> > that it's a DWIM-ish behaviour?
> 
> The latter sounds better to me.

FWIW:

1. Icicles has had such an option since 2007:
`icicle-top-level-when-sole-completion-flag'

 Non-nil means to return to top level if only
 one matching completion.  The sole completion
 is accepted.

And there's a companion option:
`icicle-top-level-when-sole-completion-delay'

 Number of secs to wait to return to top level
 if only one completion.  This has no effect if
 `icicle-top-level-when-sole-completion-flag' is
 nil.  Editing the completion (typing or deleting
 a character) before the delay expires prevents
 its automatic acceptance.

 Do not set this to 0.0.  Set it to slightly
 more than zero if you want instant action.

Maybe something like "accept-sole-completion"
would be a good name for your option?  (Emacs
no longer respects RMS's convention of `-flag'
for Boolean-valued vars).

2. Drop "-dwim-" from the name of your option.
That adds nothing but noise.  Meaningless, if
not misleading.

And does this really have anything to do with
_displaying matches_?  IIUC, it doesn't.

So far, the names proposed don't seem to
convey what (I think) this option does.

bug#53935: 27.2; [PATCH] ecomplete.el: Auto-select when there is only a single option

[Lars Ingebrigtsen]

Phil Sainty <psainty@orcon.net.nz> writes:

> I realised this would be better with some minor refactoring of
> the existing code, so I'm attaching a new version of that patch.
>
> I've used "git diff --ignore-space-change" for clarity (hence the
> indentation isn't correct).

Thanks; I've now pushed this to Emacs 29 (with minor changes).