bug#65137: 29.1; completion-substring-try-completion doesn't return the longest common substring

[Dmitry Gutov <dmitry@gutov.dev>]

On 29/08/2023 18:45, Spencer Baugh wrote:

>> Could you describe the usage scenario a little more?
>>
>>  From my brief testing, the current behavior seems okay most of the
>> time: you still get the short input which matches a bunch of strings
>> (e.g. filenames), you can type a little more chars and narrow down.
>>
>> With your change, TAB will insert the most common prefix for all those
>> completions, which in case of project-file can be a pretty long
>> string. Not a huge problem, but on the face of it that doesn't seem
>> like an improvement. So which scenario would that make better?
> 
> As a very concrete example that I ran into frequently, for
> project-find-file if you have two files:
> 
> dir/foo.ml
> dir/foo.mli
> 
> and you input "foo" and press Tab, you get "foo.ml".  But it is then
> impossible to expand that to dir/foo.ml using completion because of this
> bug.  So you have to manually select dir/foo.ml if you want to visit
> that file, either by switching to *Completions* and selecting it or by
> using minibuffer-next-completion.

Now I understand, thank you. I guess this is something that certain 
environments (such as OCaml) are more prone to than others.

Also this problem seems somewhat unique to the default completion 
mechanism. If I use Ivy, or Helm, or Vertico, or even the "bare" 
icomplete-mode, they all have the notion of the currently selected 
completion, with a short key sequence to choose it.

E.g. with icomplete-mode on I would type until the needed completion is 
highlighted in the minibuffer and then press C-j (maybe press C-, or C-. 
to select it).

The default completion, as you say, has the means to do a similar thing 
with M-<up> and M-<down>, but it's less obvious and requires more 
keypresses.

> After this bugfix, inputting "foo" and pressing Tab will expand to
> "dir/foo.ml".
> 
> In general, this bug makes it impossible to input a file name with
> completion (in project-file) if that file name is a prefix of another
> file name.  Like dir/foo and dir/foo.tar, or dir/foo.log and
> dir/foo.log.bak.

Your patch fixes that by expanding inputs into longer lines after TAB 
(meaning, the user will see their input text shift, sometimes 
considerably, to the right, and perhaps feel a little disoriented). It 
might be a minor thing, but a downside nevertheless.

I do wonder what Stefan thinks what would be the right behavior here.