Re: Navigating completions from minibuffer

[Spencer Baugh]

Juri Linkov <juri@linkov.net> writes:
>>>> Probably we have to make RET more smart, so that when more editing
>>>> was performed in the minibuffer after the completions were displayed,
>>>> then to use the minibuffer contents with exit-minibuffer,
>>>> not an obsolete completion candidate that remains selected.
>>>
>>> Interesting solution!  So if the last relevant command was changing the
>>> selected candidate, then RET submits the candidate; if the last relevant
>>> command was editing the minibuffer, then RET submits the minibuffer
>>> text.
>>>
>>> What about the case where I type some text, switch between some
>>> completion candidates in *Completions*, then decide I don't want any of
>>> them and hit RET to submit the minibuffer text?  That's something that
>>> works today.  Can we support that somehow?
>>
>> Currently the suggested way to avoid selecting a highlighted candidate
>> is to close the completions window with C-g, i.e. it adheres
>> to the principle “what you see is what you get” - when you see
>> a highlighted candidate then you will get it, otherwise you will get
>> the minibuffer contents.
>
> So there are at least 2 variants what to do when completing-read is used
> as selection rather than completion:
>
> 1. On editing the minibuffer close the completions window as expired.
>
> Shouldn't 'completion-auto-help' support this case?
> Should it have a new value 'close'?
> Or need to create a new option 'completion-auto-close'?

I think a new option would be better, the different options for
completion-auto-help all seem plausible to combine with that behavior.

It's a bit tricky since completion-auto-update=t effectively implies
completion-auto-close=t.

Oh, actually, perhaps completion-auto-close should be merged with
completion-auto-update.  Then completion-auto-update has three values:

- nil (today's behavior)
- close (close the completions window on editing the minibufer)
- t (auto-update the completions window on editing the minibuffer)

After all, both non-nil values would use basically the same
implementation.

> 2. AFAIR, 'completion-auto-update' already closes the completions window
> if none of completion candidates matches the contents of the minibuffer?
>
> So editing the minibuffer never causes a situation where a highlighted
> candidate doesn't match the minibuffer contents?
>
> And typing some characters to narrow down the completions
> always keeps the highlighted candidate selected?
>
> Then there is no problem.

Yes, that's correct.

Very interesting analysis!  This makes sense.