Re: Navigating completions from minibuffer

[T.V Raman]

Spencer Baugh <sbaugh@janestreet.com> writes:

This is a good idea. I still believe we have too many completion knobs,
but I dont know how else to simplify things other than one step at a
time and trying  it out incrementally. But we  should do this with the
final goal of recuding the current combinatorial exposion of choices
which makes things both hard to test and to explain.

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

--