Re: Navigating completions from minibuffer

[Spencer Baugh]

Juri Linkov <juri@linkov.net> writes:
>> It sets completions-auto-update to 'deselect by default, which I think
>> is reasonable?
>
> Isn't deselection needed only when minibuffer-visible-completions is enabled?

I think we could provide some nice consistency by making it always
active.

As part of this change, I think we should make sure M-RET will submit a
completion candidate even if it's been "deselected".  That would be nice
because then M-RET serves a useful purpose with
minibuffer-visible-completions=t: you can submit the previously-selected
completion candidate even if you've typed (causing deselection) since
selecting it.

With that M-RET behavior, completions-auto-update='deselect doesn't
change behavior from Emacs 29, so I think it's a plausible default.

And if we do have completions-auto-update='deselect by default, then
perhaps we can consider another change to the defaults: make RET always
submit the selected completion candidate.  That would actually change
behavior, since M-<down> followed *immediately* by RET would submit the
selected completion candidate, but maybe it's worth it?

>> minibuffer-visible-completions makes RET submit the selected
>> completion candidate, if any, ignoring the contents of the minibuffer.
>> But a user might select a completion candidate and then want to type
>> something else in the minibuffer and submit what they typed.
>>
>> * lisp/minibuffer.el (completion--insert): Add a space before each
>> candidate.
>
> I don't think anyone would like such a space shifting the whole layout
> to the right.  Rather I'd recommend to use a space after each candidate.
> There is already a space between candidates.  Only at the end a space is
> missing.
>
> Or without adding a space at the end we could change `choose-completion`
> to not select the candidate when point is at the end

Oh, yes, I definitely like the idea of not submitting the candidate when
point is at the end, no need for any extra space.  This would work well
with my thought about having M-RET to submitting even a "deselected"
candidate: the new behavior of not submitting a candidate when point is
at the end would only be active for the new command
minibuffer-choose-completion-or-exit.

> (`choose-completion` needs fixing anyway since currently it raises an
> error at the end of the first completion in case of no header.)
>
> This still won't solve the case of no header.  So in this case
> for the initial position we could add a narrow line at the top:
>
>   (propertize "\n" 'face '(:height 0))
>
> This solves a lot of problems, and will help to remove the complicated
> special-handling of the 'first-completion' text property in many places.

This seems fine to me, but as Eli points out, terminal users probably
won't like the extra "wasted" line.  Maybe if we're in the terminal and
there's no header, we could add a single space before the first
completion?