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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 65137 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: bug#65137: 29.1; completion-substring-try-completion doesn't return the longest common substring
Date: Wed, 30 Aug 2023 02:25:41 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.