From: Juri Linkov <juri@linkov.net>
To: Spencer Baugh <sbaugh@catern.com>
Cc: emacs-devel@gnu.org
Subject: Re: Updating *Completions* as you type
Date: Wed, 18 Oct 2023 09:51:17 +0300 [thread overview]
Message-ID: <86jzrk8lui.fsf@mail.linkov.net> (raw)
In-Reply-To: <874jiox1km.fsf@catern.com> (Spencer Baugh's message of "Tue, 17 Oct 2023 23:37:46 +0000 (UTC)")
>> I think preselecting the default value in the middle of completions
>> would make sense only when completions were sorted by the order of the
>> list of default values (from M-n M-n ...). Then the first default value
>> would be at the top of completions, and it would easier for users
>> to navigate completions top-down.
>
> Yes, that was the case that inspired this specific idea: the case where
> completions are sorted by the list of defaults, and so the default value
> is the first completion.
>
> But it occured to me that there's no reason to limit to just the case
> where the default value is the first completion. We can just always
> move point to the default wherever it occurs in the completions, as long
> as it occurs somewhere. Seems like a nice improvement.
>
> Although I guess it does cause M-<down> to no longer go to the first
> completion, and M-<up> to no longer go to the last one. Which is a bit
> annoying.
Indeed.
> Maybe we should have bindings to move to the first and last completions.
> Whatever they are, they should also work in completion-in-region-mode,
> though, so M-< and M-> definitely won't work... Maybe M-0 M-<down> to go
> to the first, and M-0 M-<up> to go to the last? (Or vice versa?)
M-< and M-> work in the minibuffer as well as in the normal buffer.
But they don't work with your first patch ;-)
>> BTW, while looking at this case I found a problem with your first patch:
>> after navigating in *Completions* and switching back to the minibuffer
>> point is reset to the beginning of the *Completions* buffer.
>
> Good catch! If you see my other patch which I posted in this thread,
> "Keep point on the same completion in the completions buffer", that is a
> nice orthogonal improvement which incidentally also fixes that bug in
> completions-auto-update.
Your third patch adds a new feature that just hides the bug by forcing
the previous position over the wrong new one. I think the proper fix
would be to add more commands to completions-no-auto-update-commands
in your first patch. Or to change it from opt-out to opt-in by renaming
to completions-auto-update-commands.
> OK, so maybe the thing I want to propose is not "we'll change the
> default to whatever the current selected completion is" but instead "RET
> with an empty minibuffer will submit the current selected completion".
> That's equivalent, if I drop the ideas of changing the prompt and
> changing M-RET.
Agreed, I think the idea of changing the prompt on the fly won't fly.
>>> I think this has some nice benefits in reducing the number of concepts
>>> people need to track. If the minibuffer is empty, they can just use
>>> minibuffer-next-completion a few times followed by RET to select a
>>> completion, no need to use M-RET. Plus, the new M-RET and C-u M-RET
>>> would be useful even to users who don't use minibuffer-next-completion.
>>> True, good analysis.
>>
>> Specifically though it's about the case when the minibuffer is empty. I
>> think it would be nice for RET to submit the highlighted candidate in
>> that case, if there is one.
>>
>> That matches icomplete-mode's behavior, actually, which is nice.
>
> Oh, actually it doesn't. It matches ido-mode and fido-mode and a host
> of completion mechanisms outside core, though. I still think it's
> desirable, at least as a user option.
But then such idiosyncrasy of fido-mode causes a lot of bug reports
like bug#55800.
next prev parent reply other threads:[~2023-10-18 6:51 UTC|newest]
Thread overview: 107+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 23:53 Updating *Completions* as you type sbaugh
2023-10-13 6:31 ` Eli Zaretskii
2023-10-13 18:01 ` Spencer Baugh
2023-10-14 7:09 ` Eli Zaretskii
2023-10-14 19:26 ` Björn Bidar
[not found] ` <874jit2ef7.fsf@>
2023-10-14 19:38 ` Eli Zaretskii
2023-10-14 16:51 ` Juri Linkov
2023-10-14 17:56 ` sbaugh
2023-10-14 19:51 ` Dmitry Gutov
2023-10-13 6:34 ` Juri Linkov
2023-10-13 19:04 ` Spencer Baugh
2023-10-14 16:58 ` Juri Linkov
2023-10-14 20:05 ` sbaugh
2023-10-15 6:06 ` Eli Zaretskii
2023-10-15 15:55 ` sbaugh
2023-10-16 11:38 ` Eli Zaretskii
2023-10-16 14:50 ` Michael Albinus
2023-10-16 15:58 ` [External] : " Drew Adams
2023-10-16 12:16 ` sbaugh
2023-10-17 18:23 ` Juri Linkov
2023-10-18 23:27 ` Spencer Baugh
2023-10-15 7:32 ` Juri Linkov
2023-10-16 19:28 ` Rudolf Adamkovič
2023-10-17 18:38 ` Juri Linkov
2023-10-15 20:31 ` Eshel Yaron
2023-10-16 3:18 ` [External] : " Drew Adams
2023-10-16 16:54 ` Juri Linkov
2023-10-17 13:48 ` sbaugh
2023-10-17 18:35 ` Juri Linkov
2023-10-17 22:57 ` Spencer Baugh
2023-10-18 3:04 ` [External] : " Drew Adams
2023-10-18 6:56 ` Juri Linkov
2023-10-18 12:25 ` Spencer Baugh
2023-10-18 17:32 ` Juri Linkov
2023-10-18 23:33 ` Spencer Baugh
2023-10-19 2:29 ` Spencer Baugh
2023-10-19 6:55 ` Juri Linkov
2023-11-19 19:22 ` sbaugh
2023-11-20 7:51 ` Juri Linkov
2023-11-20 15:24 ` Spencer Baugh
2023-11-20 17:47 ` Juri Linkov
2023-11-20 18:50 ` Spencer Baugh
2023-11-21 7:58 ` Juri Linkov
2023-11-21 12:40 ` sbaugh
2023-11-21 17:09 ` Juri Linkov
2023-11-21 20:45 ` Spencer Baugh
2023-11-22 7:51 ` Juri Linkov
2023-11-22 16:11 ` Spencer Baugh
2023-11-23 7:58 ` Juri Linkov
2023-11-23 12:36 ` sbaugh
2023-11-24 7:58 ` Juri Linkov
2023-11-25 16:44 ` Spencer Baugh
2023-11-25 18:31 ` Juri Linkov
2023-11-26 13:33 ` sbaugh
2023-11-27 7:28 ` Juri Linkov
2023-11-28 14:38 ` Spencer Baugh
2023-11-28 15:03 ` Eli Zaretskii
2023-11-28 17:13 ` Juri Linkov
2023-11-28 17:36 ` Eli Zaretskii
2023-11-29 7:11 ` Juri Linkov
2023-11-29 13:09 ` Eli Zaretskii
2023-11-29 14:14 ` Spencer Baugh
2023-11-29 14:54 ` Eli Zaretskii
2023-11-29 15:21 ` Spencer Baugh
2023-11-29 15:52 ` Eli Zaretskii
2023-11-29 19:17 ` Spencer Baugh
2023-11-30 6:12 ` Eli Zaretskii
2023-11-30 12:33 ` Spencer Baugh
2023-11-30 14:10 ` Eli Zaretskii
2023-11-28 23:56 ` Spencer Baugh
2023-11-29 3:33 ` Eli Zaretskii
2023-12-03 17:25 ` Juri Linkov
2023-12-03 17:56 ` Eli Zaretskii
2023-12-06 17:17 ` Juri Linkov
2023-11-28 17:16 ` Juri Linkov
2023-11-28 23:36 ` Turning completion table lambdas into symbols Spencer Baugh
2023-11-28 23:51 ` Dmitry Gutov
2023-11-29 19:26 ` Spencer Baugh
2023-12-01 0:36 ` Dmitry Gutov
2023-11-29 7:18 ` Juri Linkov
2023-11-21 12:54 ` Updating *Completions* as you type John Yates
2023-11-21 17:03 ` Juri Linkov
2023-11-21 22:27 ` John Yates
2023-10-20 6:49 ` Juri Linkov
2023-10-17 15:01 ` sbaugh
2023-10-17 18:20 ` Juri Linkov
2023-10-17 23:37 ` Spencer Baugh
2023-10-17 23:44 ` Spencer Baugh
2023-10-18 6:51 ` Juri Linkov [this message]
2023-10-18 12:47 ` Spencer Baugh
2023-10-18 17:28 ` Juri Linkov
2023-10-18 23:32 ` Spencer Baugh
2023-10-16 3:19 ` [External] : " Drew Adams
2023-10-20 9:35 ` zcomplete Philip Kaludercic
2023-10-22 17:28 ` zcomplete Juri Linkov
2023-10-23 5:00 ` zcomplete Protesilaos Stavrou
2023-10-23 6:45 ` zcomplete Juri Linkov
2023-10-13 18:11 ` Updating *Completions* as you type Daniel Semyonov
2023-10-13 18:48 ` Spencer Baugh
2023-10-16 3:16 ` [External] : " Drew Adams
2023-10-16 9:25 ` Philip Kaludercic
2023-10-16 16:03 ` Drew Adams
2023-10-20 7:45 ` Philip Kaludercic
2023-10-20 16:10 ` Drew Adams
2023-10-16 22:55 ` Emanuel Berg
2023-10-17 6:09 ` Emanuel Berg
2023-10-17 0:44 ` Michael Heerdegen
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=86jzrk8lui.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=emacs-devel@gnu.org \
--cc=sbaugh@catern.com \
/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.