Re: Navigating completions from minibuffer

[Eli Zaretskii <eliz@gnu.org>]

> 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?