[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Navigating completions from minibuffer
From: |
Eli Zaretskii |
Subject: |
Re: Navigating completions from minibuffer |
Date: |
Sat, 25 Nov 2023 18:08:44 +0200 |
> From: Spencer Baugh <sbaugh@catern.com>
> Date: Sat, 25 Nov 2023 15:19:37 +0000 (UTC)
> Cc: emacs-devel@gnu.org
>
> +(defcustom completions-auto-update 'deselect
> + "If non-nil, change the *Completions* buffer as you type.
^^^^^^
"Update", not "change".
> +If `deselect', if a completion candidate in *Completions* is
> +selected (point is on it), it will be deselected (point will be
> +moved just before it) when the minibuffer point or contents
> +change.
This has several issues.
First, "If `deselect'" is sub-optimal; it is better to say
The value of `deselect' means that ...
The double "if" ("If `deselect', if a completion candidate...") is
also sub-optimal. At the very least, if you need to say something
like that, say
If this, then if that, ...
Finally, I'm guessing that the value `deselect' means to deslect the
candidate _in_addition_to_ update "*Completions*" as the user types.
If my guess is correct, please say
The value of `deselect' means that in addition to updating
*Completions*, the selected candidate will be deselected...
> +This only affects the *Completions* buffer if it is already
> +displayed."
Not sure what this sentence adds. What will happen if you drop it?
> + :type '(choice (const :tag "*Completions* doesn't change as you type" nil)
> + (const :tag "Typing deselects any completion candidate in
> *Completions*" deselect))
And now I see that my guess above perhaps was wrong: there's no value
t in the choice? Then why not make this a simple boolean?
> +(defun completions--deselect ()
> + "If in a completion candidate, move to just after the end of it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
"If point is at a completion candidate, ..."
> +(defun completions--post-command ()
> + "Update displayed *Completions* buffer after change in minibuffer point."
> + (when (and (minibufferp) (not (eq minibuffer--old-point (point))))
> + (setq minibuffer--old-point (point))
> + (unless (and completions-auto-update
> + (memq this-command '(minibuffer-next-completion
> minibuffer-previous-completion)))
> + (completions--update-if-displayed))))
Ugh, another post-command hook... It is small wonder users complain
that Emacs is slow to respond and feels sluggish. What will happen if
the user types fast? Could there be a design that doesn't use
post-command-hook?
- Re: Navigating completions from minibuffer, (continued)
- Re: Navigating completions from minibuffer, sbaugh, 2023/11/19
- Re: Navigating completions from minibuffer, Juri Linkov, 2023/11/19
- Re: Navigating completions from minibuffer, Eli Zaretskii, 2023/11/19
- Re: Navigating completions from minibuffer, Spencer Baugh, 2023/11/19
- Re: Navigating completions from minibuffer, Juri Linkov, 2023/11/19
- Re: Navigating completions from minibuffer, Spencer Baugh, 2023/11/19
- Re: Navigating completions from minibuffer, Spencer Baugh, 2023/11/19
- Re: Navigating completions from minibuffer, sbaugh, 2023/11/23
- Re: Navigating completions from minibuffer, Juri Linkov, 2023/11/24
- Re: Navigating completions from minibuffer, Spencer Baugh, 2023/11/25
- Re: Navigating completions from minibuffer,
Eli Zaretskii <=
- Re: Navigating completions from minibuffer, sbaugh, 2023/11/25
- Re: Navigating completions from minibuffer, Juri Linkov, 2023/11/25
- Re: Navigating completions from minibuffer, sbaugh, 2023/11/26
- Re: Navigating completions from minibuffer, Eli Zaretskii, 2023/11/25
- Re: Navigating completions from minibuffer, Juri Linkov, 2023/11/25
- Re: Navigating completions from minibuffer, Spencer Baugh, 2023/11/26
- Re: Navigating completions from minibuffer, Juri Linkov, 2023/11/27
- Re: Navigating completions from minibuffer, Spencer Baugh, 2023/11/28
- Re: Navigating completions from minibuffer, Juri Linkov, 2023/11/28
- Re: Navigating completions from minibuffer, Spencer Baugh, 2023/11/28