Juri Linkov <juri@linkov.net> writes:
>> minibuffer-choose-completion-or-exit submits 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.
>
> Thanks, everything works nicely now except the special case
> of completion-show-help=nil and completions-header-format=nil.
>
> Initially the first completion is deselected, and <down> selects it.
> But when the first key typed is M-<down> the second completion
> is selected instead of the first because M-<down> moves to the
> second column when point is between the first and second completions.

I was thinking that issue is unrelated to this patch and so it could be
fixed separately.  But actually I guess this patch makes it more visible
indeed, so I guess we need to fix it now.

I think the "add a thin newline" approach is totally fine.  I did that
in my attached patch.

> A possible workaround would be to check the special property
> 'first-completion'.  But then when the logic uses text properties,
> why not to use more text properties that indicate that a candidate
> is deselected (and remove highlighting in this case) instead of
> moving point somewhere outside of the candidate?

Even if we work around this with text properties, I think it's nice for
deselection to be usually determined by location of point.  I think
that's easier to understand for the user - they should be able to
deselect or reselect something purely by moving point around, it
shouldn't require text property manipulation.