Re: Updating *Completions* as you type

[Spencer Baugh <sbaugh@catern.com>]

Juri Linkov <juri@linkov.net> writes:
>> What if the concept of "current selected completion" was unified with
>> "the default completion"?  This could be a nice, general UI.
>>
>> Specifically, with switch-to-buffer and a default of init.el:
>>
>> - If init.el is present in *Completions*, start out with point on it.
>>   This would be purely a display nicety, it wouldn't actually affect
>>   anything yet.  (This would be easy with my patch which I posted
>>   elsewhere in this thread to preserve the location of point in
>>   *Completions*)
>
> I think preselecting the default value in the middle of completions
> would make sense only when completions were sorted by the order of the
> list of default values (from M-n M-n ...).  Then the first default value
> would be at the top of completions, and it would easier for users
> to navigate completions top-down.

Yes, that was the case that inspired this specific idea: the case where
completions are sorted by the list of defaults, and so the default value
is the first completion.

But it occured to me that there's no reason to limit to just the case
where the default value is the first completion.  We can just always
move point to the default wherever it occurs in the completions, as long
as it occurs somewhere.  Seems like a nice improvement.

Although I guess it does cause M-<down> to no longer go to the first
completion, and M-<up> to no longer go to the last one.  Which is a bit
annoying.

Maybe we should have bindings to move to the first and last completions.
Whatever they are, they should also work in completion-in-region-mode,
though, so M-< and M-> definitely won't work... Maybe M-0 M-<down> to go
to the first, and M-0 M-<up> to go to the last?  (Or vice versa?)

>> - If and when the user invokes minibuffer-next-completion:
>>   - The default changes to whatever the new selected completion is
>>   - The prompt text "(default init.el)" changes permanently to literally
>>     "(default selected completion)"
>
> Changing the prompt might interfere with such packages as minibuf-eldef.el
> and other cases of customized minibuffer-default-prompt-format.

I think as long as we use format-prompt, minibuf-eldef.el and customized
values of minibuffer-default-prompt-format will still work.  Something
to be careful about though.  Changing the prompt text isn't essential,
anyway - it may just be a bit confusing if it's not changed.

> Also this might break commands that manually handle the default value
> for empty input.

As long as the default value is present in the completions, the user can
always select it again.  Or the user can always just do M-n to select
the original default value - I don't expect this would change that.

>> - RET, as always, chooses the default if the minibuffer is empty; if the
>>   user has done minibuffer-next-completion, the default is the selected
>>   completion, so RET will choose that.
>> - M-RET (minibuffer-choose-completion) is replaced with a new command
>>   which immediately chooses the default, whatever it is, ignoring the
>>   current contents of the minibuffer
>
> What should RET do after the user navigated in *Completions* and
> switched back to the minibuffer.  A different candidate is highlighted
> in *Completions*, while the default value remains unchanged.

RET should probably choose the highlighted candidate in *Completions* in
that case.

BTW to be clear I don't mean that we would actually change
minibuffer-default; just that RET with an empty minibuffer would provide
the current selected completion rather than minibuffer-default.

> BTW, while looking at this case I found a problem with your first patch:
> after navigating in *Completions* and switching back to the minibuffer
> point is reset to the beginning of the *Completions* buffer.

Good catch!  If you see my other patch which I posted in this thread,
"Keep point on the same completion in the completions buffer", that is a
nice orthogonal improvement which incidentally also fixes that bug in
completions-auto-update.

>> - C-u M-RET inserts the default in the the minibuffer, without exiting
>>   (matching the behavior of C-u minibuffer-choose-completion)
>
> Usually the default is inserted by M-n.

True, and I don't expect to change that.  I guess that's probably
sufficient.

OK, so maybe the thing I want to propose is not "we'll change the
default to whatever the current selected completion is" but instead "RET
with an empty minibuffer will submit the current selected completion".
That's equivalent, if I drop the ideas of changing the prompt and
changing M-RET.

>> 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.
>
> It seems this is intended to solve the problem of a mismatch between
> the highlighted candidate and the contents of the minibuffer?
> Such problem exists, for example, in icomplete-mode where
> RET returns the contents of the minibuffer, so a special key 'C-j'
> is dedicated to select the highlighted candidate.  For selecting
> a highlighted candidate from *Completions* such key is 'M-RET'.

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.

>> I also think this would make it less painful to set
>> minibuffer-completion-auto-choose to nil, which matches
>> completion-in-region better and also works much better with
>> completions-auto-update.
>
> Sorry, I don't understand how this would make
> minibuffer-completion-auto-choose=nil less painful.
>
> Since there is no concept of the default value for completion-in-region,
> 'M-RET' is the only way to choose the highlighted candidate.

Eh, this aspect is probably specific to me.