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

[Spencer Baugh <sbaugh@janestreet.com>]

Dmitry Gutov <dmitry@gutov.dev> writes:
> Hi Spencer!
>
> On 08/08/2023 02:24, Spencer Baugh wrote:
>> However, even this does not work in the project-file and xref-location
>> completion categories, for which the "basic" style is not included in
>> completion-category-defaults.  For such completion categories, there's
>> simply no way to use completion to insert a common prefix.  This is bad,
>> because a filename or identifier might easily be a prefix of another
>> filename or identifier.
>
> 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.

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.