GNU bug report logs - #77253
30.1.50; Support RET choosing the selected completion without rebinding arrow keys

Previous Next

To reply to this bug, email your comments to 77253 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Cc: juri <at> linkov.net
Subject: 30.1.50; Support RET choosing the selected completion without
 rebinding arrow keys
Date: Tue, 25 Mar 2025 11:10:57 -0400

Right now, minibuffer-visible-completions does two things, only when
*Completions* is visible:

A. If there's a selected completion candidate, RET exits the minibuffer
with it.

B. The arrow keys move point in the *Completions* buffer instead of the
minibuffer, to select completion candidates.

These are really two separate things.

A is a nice behavior for novice users, but B is difficult for novice
users (who like to use the arrow keys for moving point) to deal with.

We should make them separately configurable, or at least allow enabling
the RET behavior without the arrow keys behavior.

And with the addition of completion-auto-deselect, the RET behavior is
actually a plausible default behavior: it only takes effect if the user
has manually selected a completion candidate with M-<up>/M-<down>, and
the selected candidate is automatically deselected if the user types
more.  So it won't affect anyone who isn't explicitly making use of
M-<up>/M-<down>.

So I suggest we should add a new defcustom to change the RET behavior in
the presence of a selected completion candidate, and default it to t.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: 30.1.50; Support RET choosing the selected completion without
 rebinding arrow keys
Date: Tue, 25 Mar 2025 19:19:38 +0200

> Right now, minibuffer-visible-completions does two things, only when
> *Completions* is visible:
>
> A. If there's a selected completion candidate, RET exits the minibuffer
> with it.
>
> B. The arrow keys move point in the *Completions* buffer instead of the
> minibuffer, to select completion candidates.
>
> These are really two separate things.
>
> A is a nice behavior for novice users, but B is difficult for novice
> users (who like to use the arrow keys for moving point) to deal with.

Not sure why this would be difficult for novice users, but maybe adding
a new value to the existing defcustom minibuffer-visible-completions
would be sufficient?

Message #11 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Tue, 25 Mar 2025 13:25:09 -0400

Juri Linkov <juri <at> linkov.net> writes:
>> Right now, minibuffer-visible-completions does two things, only when
>> *Completions* is visible:
>>
>> A. If there's a selected completion candidate, RET exits the minibuffer
>> with it.
>>
>> B. The arrow keys move point in the *Completions* buffer instead of the
>> minibuffer, to select completion candidates.
>>
>> These are really two separate things.
>>
>> A is a nice behavior for novice users, but B is difficult for novice
>> users (who like to use the arrow keys for moving point) to deal with.
>
> Not sure why this would be difficult for novice users,

Well, because they like using the arrow keys. :)

> but maybe adding a new value to the existing defcustom
> minibuffer-visible-completions would be sufficient?

That would work, but I guess I also propose that we should change the
implementation a bit.  The use of a menu-item :filter binding is clever,
but I think it would be nicer to have a normal binding for RET which
just checks if *Completions* is shown/a completion candidate is
selected.  For one thing, then C-h k RET will behave more expectedly.

Message #14 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Wed, 26 Mar 2025 09:52:05 +0200

>>> Right now, minibuffer-visible-completions does two things, only when
>>> *Completions* is visible:
>>>
>>> A. If there's a selected completion candidate, RET exits the minibuffer
>>> with it.
>>>
>>> B. The arrow keys move point in the *Completions* buffer instead of the
>>> minibuffer, to select completion candidates.
>>>
>>> These are really two separate things.
>>>
>>> A is a nice behavior for novice users, but B is difficult for novice
>>> users (who like to use the arrow keys for moving point) to deal with.
>>
>> Not sure why this would be difficult for novice users,
>
> Well, because they like using the arrow keys. :)

But they like using the arrow keys to select a completion candidate too.
This is how they use arrow keys e.g. in a web browser in the address bar.
At least up/down arrows navigate completions, while left/right arrows
indeed move the cursor in the address bar.

So we need separate values for up/down and left/right arrows?

>> but maybe adding a new value to the existing defcustom
>> minibuffer-visible-completions would be sufficient?
>
> That would work, but I guess I also propose that we should change the
> implementation a bit.  The use of a menu-item :filter binding is clever,
> but I think it would be nicer to have a normal binding for RET which
> just checks if *Completions* is shown/a completion candidate is
> selected.  For one thing, then C-h k RET will behave more expectedly.

Removing the :filter binding would be fine, if it won't cause other problems.
At least it would be nice to try to see how this works with :filter.

Message #17 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Wed, 26 Mar 2025 10:06:20 -0400

Juri Linkov <juri <at> linkov.net> writes:

>>>> Right now, minibuffer-visible-completions does two things, only when
>>>> *Completions* is visible:
>>>>
>>>> A. If there's a selected completion candidate, RET exits the minibuffer
>>>> with it.
>>>>
>>>> B. The arrow keys move point in the *Completions* buffer instead of the
>>>> minibuffer, to select completion candidates.
>>>>
>>>> These are really two separate things.
>>>>
>>>> A is a nice behavior for novice users, but B is difficult for novice
>>>> users (who like to use the arrow keys for moving point) to deal with.
>>>
>>> Not sure why this would be difficult for novice users,
>>
>> Well, because they like using the arrow keys. :)
>
> But they like using the arrow keys to select a completion candidate too.
> This is how they use arrow keys e.g. in a web browser in the address bar.
> At least up/down arrows navigate completions, while left/right arrows
> indeed move the cursor in the address bar.

That is true.

> So we need separate values for up/down and left/right arrows?

That would probably be good, yes.

But, here's another factor: The *Completions* buffer by default contains
a help message explaining to users that they can use M-<up> and M-<down>
to select completions.  There's no such message explaining to users that
they can use C-b/C-f/C-n/C-p to move point.  So:

- If the arrow keys move point, users can still figure out how to select
  completions by reading the help text.

- If the arrow keys select completions, users who don't know
  C-b/C-f/C-n/C-p are basically helpless.  (This is sadly common at my
  site, because most of our users use evil-mode and don't know
  C-b/C-f/C-n/C-p)

Also, rebinding the arrow keys by default to select completions is
probably an unacceptable behavior change.  But it's very possible to
rebind RET to accept completions by default.  So even if we disregard
the "novice user" argument, I still think we should investigate binding
RET without rebinding the arrow keys.

>>> but maybe adding a new value to the existing defcustom
>>> minibuffer-visible-completions would be sufficient?
>>
>> That would work, but I guess I also propose that we should change the
>> implementation a bit.  The use of a menu-item :filter binding is clever,
>> but I think it would be nicer to have a normal binding for RET which
>> just checks if *Completions* is shown/a completion candidate is
>> selected.  For one thing, then C-h k RET will behave more expectedly.
>
> Removing the :filter binding would be fine, if it won't cause other problems.
> At least it would be nice to try to see how this works with :filter.

I'm curious: Why do you prefer the :filter approach?  Does it avoid some
problems that happened in the past?  It makes sense for the arrow keys,
but if we are rebinding RET by default, :filter seems like an unusual
thing to use.

Message #20 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Thu, 27 Mar 2025 19:50:13 +0200

> But, here's another factor: The *Completions* buffer by default contains
> a help message explaining to users that they can use M-<up> and M-<down>
> to select completions.  There's no such message explaining to users that
> they can use C-b/C-f/C-n/C-p to move point.  So:
>
> - If the arrow keys move point, users can still figure out how to select
>   completions by reading the help text.
>
> - If the arrow keys select completions, users who don't know
>   C-b/C-f/C-n/C-p are basically helpless.  (This is sadly common at my
>   site, because most of our users use evil-mode and don't know
>   C-b/C-f/C-n/C-p)

When users need to move point with arrow keys, then they have
to close the completions window.  This is the purpose of
'minibuffer-visible-completions': to eliminate ambiguity
whether arrows/RET apply to the visible completions window,
or to the text in the minibuffer.

> Also, rebinding the arrow keys by default to select completions is
> probably an unacceptable behavior change.  But it's very possible to
> rebind RET to accept completions by default.  So even if we disregard
> the "novice user" argument, I still think we should investigate binding
> RET without rebinding the arrow keys.

Not sure if it's possible for RET to accept the selected candidate
by default since users might prefer to accept text in the minibuffer.

> I'm curious: Why do you prefer the :filter approach?  Does it avoid some
> problems that happened in the past?  It makes sense for the arrow keys,
> but if we are rebinding RET by default, :filter seems like an unusual
> thing to use.

:filter makes it easier to add conditional keybindings that share
the same condition.  I doubt if it would be possible to rebind RET
by default.  But need to try to see how it works.

Message #23 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Thu, 27 Mar 2025 16:42:29 -0400

Juri Linkov <juri <at> linkov.net> writes:
>> But, here's another factor: The *Completions* buffer by default contains
>> a help message explaining to users that they can use M-<up> and M-<down>
>> to select completions.  There's no such message explaining to users that
>> they can use C-b/C-f/C-n/C-p to move point.  So:
>>
>> - If the arrow keys move point, users can still figure out how to select
>>   completions by reading the help text.
>>
>> - If the arrow keys select completions, users who don't know
>>   C-b/C-f/C-n/C-p are basically helpless.  (This is sadly common at my
>>   site, because most of our users use evil-mode and don't know
>>   C-b/C-f/C-n/C-p)
>
> When users need to move point with arrow keys, then they have
> to close the completions window.  This is the purpose of
> 'minibuffer-visible-completions': to eliminate ambiguity
> whether arrows/RET apply to the visible completions window,
> or to the text in the minibuffer.

Yes, and I'm definitely a fan of minibuffer-visible-completions, but
just to name a few problems:

- It's not necessarily obvious that closing the completions window will
  make the arrow keys operate in the minibuffer.  Actually, maybe we
  should update the completion help text to say that?  That might help a
  lot.

- The new completion-eager-display makes *Completions* pop up
  immediately; when this happens, it can be surprising that the arrow
  keys don't work in the minibuffer from the very start of the
  minibuffer session.

But again, I like minibuffer-visible-completions a lot, I'm just
wondering about other points in the design space.

>> Also, rebinding the arrow keys by default to select completions is
>> probably an unacceptable behavior change.  But it's very possible to
>> rebind RET to accept completions by default.  So even if we disregard
>> the "novice user" argument, I still think we should investigate binding
>> RET without rebinding the arrow keys.
>
> Not sure if it's possible for RET to accept the selected candidate
> by default since users might prefer to accept text in the minibuffer.

If there's a selected candidate, though, then users have already decided
to use M-<up>/M-<down> to interact with completions.  (Or they've
switched to the completions buffer and selected one)

If they decide they don't want the candidate they selected, and want to
continue with text in the minibuffer, completion-auto-deselect will
automatically deselect the candidate if they type anything.

I think these two facts combined make it possible for RET to accept the
selected candidate by default.

>> I'm curious: Why do you prefer the :filter approach?  Does it avoid some
>> problems that happened in the past?  It makes sense for the arrow keys,
>> but if we are rebinding RET by default, :filter seems like an unusual
>> thing to use.
>
> :filter makes it easier to add conditional keybindings that share
> the same condition.  I doubt if it would be possible to rebind RET
> by default.  But need to try to see how it works.

Makes sense.  I'll try.

Message #26 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Fri, 28 Mar 2025 09:20:43 +0200

> - It's not necessarily obvious that closing the completions window will
>   make the arrow keys operate in the minibuffer.  Actually, maybe we
>   should update the completion help text to say that?  That might help a
>   lot.

Maybe it's possible to squeeze this help text just into one additional line?
Something like:

  Type 'C-g' to close this window and restore arrows to move point.

> - The new completion-eager-display makes *Completions* pop up
>   immediately; when this happens, it can be surprising that the arrow
>   keys don't work in the minibuffer from the very start of the
>   minibuffer session.

Then another possible value for 'minibuffer-visible-completions'
would be to not rebind left/right arrows when the completions window
contains only one column (like on the browser's address bar).

>> Not sure if it's possible for RET to accept the selected candidate
>> by default since users might prefer to accept text in the minibuffer.
>
> If there's a selected candidate, though, then users have already decided
> to use M-<up>/M-<down> to interact with completions.  (Or they've
> switched to the completions buffer and selected one)
>
> If they decide they don't want the candidate they selected, and want to
> continue with text in the minibuffer, completion-auto-deselect will
> automatically deselect the candidate if they type anything.
>
> I think these two facts combined make it possible for RET to accept the
> selected candidate by default.

Makes sense.  So we need to try how well it performs.

Message #29 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Juri Linkov <juri <at> linkov.net>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Thu, 03 Apr 2025 13:52:44 -0400

Juri Linkov <juri <at> linkov.net> writes:

>> - It's not necessarily obvious that closing the completions window will
>>   make the arrow keys operate in the minibuffer.  Actually, maybe we
>>   should update the completion help text to say that?  That might help a
>>   lot.
>
> Maybe it's possible to squeeze this help text just into one additional line?
> Something like:
>
>   Type 'C-g' to close this window and restore arrows to move point.

Maybe we don't even need an additional line?  How about:

Click or type RET on a completion to select it, or C-g to close this window.
Type <right>, <left>, <down>, <up> to move point between completions.

>> - The new completion-eager-display makes *Completions* pop up
>>   immediately; when this happens, it can be surprising that the arrow
>>   keys don't work in the minibuffer from the very start of the
>>   minibuffer session.
>
> Then another possible value for 'minibuffer-visible-completions'
> would be to not rebind left/right arrows when the completions window
> contains only one column (like on the browser's address bar).

True.  Though I guess that could maybe be the default behavior when
completions-format=one-column.

>>> Not sure if it's possible for RET to accept the selected candidate
>>> by default since users might prefer to accept text in the minibuffer.
>>
>> If there's a selected candidate, though, then users have already decided
>> to use M-<up>/M-<down> to interact with completions.  (Or they've
>> switched to the completions buffer and selected one)
>>
>> If they decide they don't want the candidate they selected, and want to
>> continue with text in the minibuffer, completion-auto-deselect will
>> automatically deselect the candidate if they type anything.
>>
>> I think these two facts combined make it possible for RET to accept the
>> selected candidate by default.
>
> Makes sense.  So we need to try how well it performs.

How about this?

(BTW, after writing minibuffer--completions-visible, I'm wondering if
most of the code which calls (get-buffer-window "*Completions*" 0) is
actually buggy, because it's not checking completion-reference-buffer.
Should we replace ~all the calls to (get-buffer-window "*Completions*"
0) with (minibuffer--completions-visible) which does check that?)

diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 404fa143194..c026e41a818 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -3209,6 +3209,12 @@ completion-help-at-point
   (define-key map "\n" 'exit-minibuffer)
   (define-key map "\r" 'exit-minibuffer))
 
+(defun minibuffer-choose-completion-just-exit (&optional no-exit)
+  "Choose the selected completion from the minibuffer or call `exit-minibuffer'."
+  (interactive "P")
+  (or (minibuffer-choose-completion-if-selected no-exit)
+      (minibuffer-exit)))
+
 (defvar-keymap minibuffer-local-completion-map
   :doc "Local keymap for minibuffer input with completion."
   :parent minibuffer-local-map
@@ -3218,6 +3224,7 @@ minibuffer-local-completion-map
   ;; another binding for it.
   ;; "M-TAB"  #'minibuffer-force-complete
   "SPC"       #'minibuffer-complete-word
+  "RET"       #'minibuffer-choose-completion-just-exit
   "?"         #'minibuffer-completion-help
   "<prior>"   #'switch-to-completions
   "M-v"       #'switch-to-completions
@@ -3229,7 +3236,7 @@ minibuffer-local-completion-map
 (defvar-keymap minibuffer-local-must-match-map
   :doc "Local keymap for minibuffer input with completion, for exact match."
   :parent minibuffer-local-completion-map
-  "RET" #'minibuffer-complete-and-exit
+  "RET" #'minibuffer-choose-completion-or-exit
   "C-j" #'minibuffer-complete-and-exit)
 
 (defvar-keymap minibuffer-local-filename-completion-map
@@ -3326,18 +3333,34 @@ minibuffer-visible-completions
 (defvar minibuffer-visible-completions--always-bind nil
   "If non-nil, force the `minibuffer-visible-completions' bindings on.")
 
+(defun minibuffer--completions-visible ()
+  "Return the window where the *Completions* buffer for this minibuffer is visible."
+  (when-let ((window (get-buffer-window "*Completions*" 0)))
+    (when (eq (buffer-local-value 'completion-reference-buffer
+                                  (window-buffer window))
+              (window-buffer (active-minibuffer-window)))
+      window)))
+
+(defun minibuffer-choose-completion-if-selected (&optional no-exit no-quit)
+  "Like `minibuffer-choose-completion', but do nothing if no candidate is selected.
+
+Return non-nil if a completion was chosen."
+  (when-let* ((window (minibuffer--completions-visible)))
+    (with-selected-window window
+      ;; Detect selection as if `choose-completion-deselect-if-after' is nil.
+      (when (get-text-property (point) 'completion--string)
+        (choose-completion nil no-exit no-quit)
+        t))))
+
 (defun minibuffer-visible-completions--filter (cmd)
   "Return CMD if `minibuffer-visible-completions' bindings should be active."
   (if minibuffer-visible-completions--always-bind
       cmd
-    (when-let ((window (get-buffer-window "*Completions*" 0)))
-      (when (and (eq (buffer-local-value 'completion-reference-buffer
-                                         (window-buffer window))
-                     (window-buffer (active-minibuffer-window)))
-                 (if (eq cmd #'minibuffer-choose-completion-or-exit)
-                     (with-current-buffer (window-buffer window)
-                       (get-text-property (point) 'completion--string))
-                   t))
+    (when-let ((window (minibuffer--completions-visible)))
+      (when (if (eq cmd #'minibuffer-choose-completion-or-exit)
+                (with-current-buffer (window-buffer window)
+                  (get-text-property (point) 'completion--string))
+              t)
         cmd))))
 
 (defun minibuffer-visible-completions--bind (binding)
@@ -5109,10 +5132,8 @@ minibuffer-choose-completion-or-exit
 in the completions window, then exit the minibuffer using its present
 contents."
   (interactive "P")
-  (condition-case nil
-      (let ((choose-completion-deselect-if-after t))
-        (minibuffer-choose-completion no-exit no-quit))
-    (error (minibuffer-complete-and-exit))))
+  (or (minibuffer-choose-completion-if-selected no-exit no-quit)
+      (minibuffer-complete-and-exit)))
 
 (defun minibuffer-complete-history ()
   "Complete as far as possible using the minibuffer history.

Message #32 received at 77253 <at> debbugs.gnu.org (full text, mbox):

From: Juri Linkov <juri <at> linkov.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 77253 <at> debbugs.gnu.org
Subject: Re: bug#77253: 30.1.50; Support RET choosing the selected
 completion without rebinding arrow keys
Date: Thu, 03 Apr 2025 21:19:16 +0300

>>> - It's not necessarily obvious that closing the completions window will
>>>   make the arrow keys operate in the minibuffer.  Actually, maybe we
>>>   should update the completion help text to say that?  That might help a
>>>   lot.
>>
>> Maybe it's possible to squeeze this help text just into one additional line?
>> Something like:
>>
>>   Type 'C-g' to close this window and restore arrows to move point.
>
> Maybe we don't even need an additional line?  How about:
>
> Click or type RET on a completion to select it, or C-g to close this window.
> Type <right>, <left>, <down>, <up> to move point between completions.

Looks good.

>>> - The new completion-eager-display makes *Completions* pop up
>>>   immediately; when this happens, it can be surprising that the arrow
>>>   keys don't work in the minibuffer from the very start of the
>>>   minibuffer session.
>>
>> Then another possible value for 'minibuffer-visible-completions'
>> would be to not rebind left/right arrows when the completions window
>> contains only one column (like on the browser's address bar).
>
> True.  Though I guess that could maybe be the default behavior when
> completions-format=one-column.

Agreed.

>>>> Not sure if it's possible for RET to accept the selected candidate
>>>> by default since users might prefer to accept text in the minibuffer.
>>>
>>> If there's a selected candidate, though, then users have already decided
>>> to use M-<up>/M-<down> to interact with completions.  (Or they've
>>> switched to the completions buffer and selected one)
>>>
>>> If they decide they don't want the candidate they selected, and want to
>>> continue with text in the minibuffer, completion-auto-deselect will
>>> automatically deselect the candidate if they type anything.
>>>
>>> I think these two facts combined make it possible for RET to accept the
>>> selected candidate by default.
>>
>> Makes sense.  So we need to try how well it performs.
>
> How about this?

Thanks, will try to use for a while.

> (BTW, after writing minibuffer--completions-visible, I'm wondering if
> most of the code which calls (get-buffer-window "*Completions*" 0) is
> actually buggy, because it's not checking completion-reference-buffer.
> Should we replace ~all the calls to (get-buffer-window "*Completions*"
> 0) with (minibuffer--completions-visible) which does check that?)

Looks right, for example for the case of recursive minibuffers.

> +      (minibuffer-exit)))

Typo: 'exit-minibuffer'.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.