Re: Updating *Completions* as you type

[Spencer Baugh]

Juri Linkov <juri@linkov.net> writes:
>>>>>> I think this has some nice benefits in reducing the number of concepts
>>>>>> people need to track.  If the minibuffer is empty, they can just use
>>>>>> minibuffer-next-completion a few times followed by RET to select a
>>>>>> completion, no need to use M-RET.  Plus, the new M-RET and C-u M-RET
>>>>>> would be useful even to users who don't use minibuffer-next-completion.
>>>>>> True, good analysis.
>>>>>
>>>>> Specifically though it's about the case when the minibuffer is empty.  I
>>>>> think it would be nice for RET to submit the highlighted candidate in
>>>>> that case, if there is one.
>>>>>
>>>>> That matches icomplete-mode's behavior, actually, which is nice.
>>>>
>>>> Oh, actually it doesn't.  It matches ido-mode and fido-mode and a host
>>>> of completion mechanisms outside core, though.  I still think it's
>>>> desirable, at least as a user option.
>>>
>>> But then such idiosyncrasy of fido-mode causes a lot of bug reports
>>> like bug#55800.
>>
>> But we would not have those kinds of issues because when completion
>> starts, by default, there is no highlighted candidate.
>
> And the issue occurs as soon as the first candidate is highlighted.

Yes, but that's something the user explicitly chooses to do.  (as long
as we don't preselect completions, which (notwithstanding my patch which
does that) I don't think we should do)

And even if they highlight a candidate, they can always unhighlight by
running minibuffer-completion-help (? or M-?) again.

That's a big advantage we have over fido-mode and icomplete, which lets
us avoid this class of problems: We have a way to represent the state
where no candidate is selected/highlighted.