Re: Updating *Completions* as you type

[Juri Linkov <juri@linkov.net>]

>>>> 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.
>>
>> Your third patch adds a new feature that just hides the bug by forcing
>> the previous position over the wrong new one.  I think the proper fix
>> would be to add more commands to completions-no-auto-update-commands
>> in your first patch.  Or to change it from opt-out to opt-in by renaming
>> to completions-auto-update-commands.
>
> I would much rather not list commands as opt-in or opt-out at all, I'd
> rather all commands just work without special cases.  So I'm working on
> features to allow that.
>
> I don't agree with the characterization of "it just hides the bug".  The
> bug is that point in *Completions* gets wiped out by auto-updating.  My
> third patch preserves point across auto-updating.  That's very directly
> solving the bug.

I agree it's helpful to keep point on the selected candidate while
adding characters to the completion.  But the problem is that point
is kept for too long that affects later unralated commands.

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