all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: emacs-devel@gnu.org
Subject: Re: Navigating completions from minibuffer
Date: Wed, 15 Nov 2023 17:03:49 -0500	[thread overview]
Message-ID: <ierh6lmk722.fsf@janestreet.com> (raw)
In-Reply-To: 864jhokelp.fsf@mail.linkov.net

Juri Linkov <juri@linkov.net> writes:
>>>> Probably we have to make RET more smart, so that when more editing
>>>> was performed in the minibuffer after the completions were displayed,
>>>> then to use the minibuffer contents with exit-minibuffer,
>>>> not an obsolete completion candidate that remains selected.
>>>
>>> Interesting solution!  So if the last relevant command was changing the
>>> selected candidate, then RET submits the candidate; if the last relevant
>>> command was editing the minibuffer, then RET submits the minibuffer
>>> text.
>>>
>>> What about the case where I type some text, switch between some
>>> completion candidates in *Completions*, then decide I don't want any of
>>> them and hit RET to submit the minibuffer text?  That's something that
>>> works today.  Can we support that somehow?
>>
>> Currently the suggested way to avoid selecting a highlighted candidate
>> is to close the completions window with C-g, i.e. it adheres
>> to the principle “what you see is what you get” - when you see
>> a highlighted candidate then you will get it, otherwise you will get
>> the minibuffer contents.
>
> So there are at least 2 variants what to do when completing-read is used
> as selection rather than completion:
>
> 1. On editing the minibuffer close the completions window as expired.

This would make it difficult to narrow the completions by typing in some
text from them, though.  I think I relatively often:

1. TAB
2. Look at *Completions*
3. Type in some text from one of them

Step 3 would harder if *Completions* disappeared on the first character
I typed.

Perhaps instead typing a character could deselect the currently selected
completion, rather than hide *Completions*?  But it seems nice to
maintain the selected completion as you type, as a visual guide, and
also my other patch maintains the selected completion between each TAB,
which is nice.

Maybe... we could somehow de-activate the selected completion, visually
de-emphasizing it in some way, but still showing its position in some
less-significant way?  An underline, perhaps?  And subsequent operations
which change the selected completion would reactivate it, making it the
selected completion again.  That might be a bit tricky to represent
visually in an intuitive way, but it might give us everything we want.

Maybe we could represent that visually by moving the selected completion
indicator (which in emacs -q is a green highlight) to *the minibuffer*
when the "selected" completion is not actually active.  Then the user
would quite quickly get the idea: RET submits whatever is highlighted in
green.




  parent reply	other threads:[~2023-11-15 22:03 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-07  3:57 Navigating completions from minibuffer T.V Raman
2023-11-07  4:55 ` T.V Raman
2023-11-07  7:20   ` Juri Linkov
2023-11-07 17:53     ` T.V Raman
2023-11-07 19:36       ` T.V Raman
2023-11-08  7:39         ` Juri Linkov
2023-11-08 16:21           ` T.V Raman
2023-11-08 17:18             ` T.V Raman
2023-11-08 22:11               ` Slow completion-at-point was " T.V Raman
2023-11-09  7:22                 ` Slow completion-at-point Juri Linkov
2023-11-09 12:10                   ` Dmitry Gutov
2023-11-09 16:20                     ` Juri Linkov
2023-11-09 18:32                       ` João Távora
2023-11-11  2:48                     ` T.V Raman
2023-11-11 10:36                       ` Dmitry Gutov
2023-11-11 16:40                         ` T.V Raman
2023-11-11 19:00                           ` Juri Linkov
2023-11-11 19:43                             ` T.V Raman
2023-11-11 21:50                               ` Dmitry Gutov
2023-11-09 15:39                   ` T.V Raman
2023-11-09 12:20                 ` Slow completion-at-point was Re: Navigating completions from minibuffer Dmitry Gutov
2023-11-09 15:41                   ` T.V Raman
2023-11-09 17:46                 ` T.V Raman
2023-11-10 13:12           ` Spencer Baugh
2023-11-11 18:58             ` Juri Linkov
2023-11-14  7:36               ` Juri Linkov
2023-11-15 21:40                 ` Spencer Baugh
2023-11-16 17:15                   ` T.V Raman
2023-11-15 22:03                 ` Spencer Baugh [this message]
2023-11-16  7:16                   ` Juri Linkov
2023-11-16 14:41                     ` Spencer Baugh
2023-11-16 17:28                       ` Juri Linkov
2023-11-16 18:25                         ` Spencer Baugh
2023-11-17  7:09                           ` Juri Linkov
2023-11-17 17:22                             ` Spencer Baugh
2023-11-18 20:58                               ` sbaugh
2023-11-19  7:08                                 ` Juri Linkov
2023-11-19  8:19                                   ` Eli Zaretskii
2023-11-19 14:41                                   ` Spencer Baugh
2023-11-19 18:01                                     ` Juri Linkov
2023-11-19 19:41                                       ` Spencer Baugh
2023-11-20  2:58                                       ` Spencer Baugh
2023-11-23 13:39                                     ` sbaugh
2023-11-24  7:54                                       ` Juri Linkov
2023-11-25 15:19                                         ` Spencer Baugh
2023-11-25 16:08                                           ` Eli Zaretskii
2023-11-25 18:23                                             ` sbaugh
2023-11-25 18:48                                               ` Juri Linkov
2023-11-26 13:10                                                 ` sbaugh
2023-11-25 19:00                                               ` Eli Zaretskii
2023-11-25 17:46                                           ` Juri Linkov
2023-11-26 14:33                                             ` Spencer Baugh
2023-11-27  7:22                                               ` Juri Linkov
2023-11-28 14:48                                                 ` Spencer Baugh
2023-11-28 17:23                                                   ` Juri Linkov
2023-11-29  0:20                                                     ` Spencer Baugh
2023-12-03 17:21                                                       ` Juri Linkov
2023-12-03 18:13                                                         ` Eli Zaretskii
2023-12-06 17:20                                                           ` Juri Linkov
2023-12-06 17:50                                                             ` Eli Zaretskii
2023-12-07  7:44                                                               ` Juri Linkov
2023-12-08  8:46                                                                 ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ierh6lmk722.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.