Re: Navigating completions from minibuffer

[Juri Linkov]

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

Please note that currently there is no need to use M-RET by default
because the default value of minibuffer-completion-auto-choose is t,
and M-down inserts the candidate that is accepted by RET.

So M-RET could help only in case of minibuffer-visible-completions=t
when the editing deselected a completion candidate.

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

I doubt that any change of the default behavior would be acceptable.

>>> * 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.

Agreed, so M-RET will override the logic of RET.

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

A single space the first completion will break the vertical alignment.