Subject: Re: bug#77718: 31.0.50; completion styles substring and flex are broken

From: Spencer Baugh <[email-masked]>
Date: Tue, 17 Jun 2025 15:26:36 -0400

Stephen Berman <[email-masked]> writes:

> On Tue, 17 Jun 2025 10:59:56 -0400 Spencer Baugh <[email-masked]> wrote:
>
>> Stephen Berman <[email-masked]> writes:
>>> On Mon, 02 Jun 2025 12:38:06 +0200 Stephen Berman <[email-masked]> wrote:
>>>
>>>> On Fri, 02 May 2025 14:44:04 +0200 Stephen Berman <[email-masked]> wrote:
>>>>
>>>>> On Fri, 2 May 2025 08:26:44 -0400 Spencer Baugh <[email-masked]> wrote:
>>>>>
>>>>>> On Fri, May 2, 2025, 4:30 AM Stephen Berman <[email-masked]> wrote:
>>>>>
>>>>>>> What about the other regression I mentioned?  Have you looked at that
>>>>>>> and tried the fix for it I included?  If there are no objections to that
>>>>>>> patch, I'd like to install it on master.  Or if there are problems with
>>>>>>> it, I'd welcome a better fix.
>>>>>>>
>>>>>>
>>>>>> That fix is not right and would cause other issues.
>>>>>
>>>>> When you have the opportunity, please say what those issues are; I have
>>>>> been using my patch since the first version of your changes that
>>>>> introduced this regression and don't recall any issues with it with my
>>>>> setup, but admittedly I haven't extensive testing with -Q or other
>>>>> configurations.
>>>>
>>>> Do you have a rough ETA for fixing this regression?  And again, can you
>>>> please explain what's wrong with my fix?
>>>
>>> Progress on this issue seems to be stalled.  I have no reason to doubt
>>> my fix may be problematic for use cases I haven't encountered, but I
>>> don't know what these are, so I cannot reasonably investigate further.
>>> If my patch is installed, those who encounter any problems due to it can
>>> report them, which hopefully will facilitate finding a better fix.
>>> Therefore, I request permission to install my patch.  If it causes
>>> serious problems for which there is no quick fix, it can be reverted.
>>
>> There is no other regression.  rfn-eshadow works correctly, graying out
>> the section of the minibuffer text which will be removed by
>> substitute-in-file-name when read-file-name returns, even if point is in
>> that section of the text.  This has always been the case.  Likewise, the
>> pcm-based completion styles sometimes move point into that text on
>> try-completion.  This has also always been the case.  So there is no
>> other regression.
>
> I'm not sure what you mean by "no other regression", but what I reported
> upstream still holds in current master.  That is, start Emacs like this:
>
> emacs -Q --eval "(custom-set-variables '(completion-category-overrides '((file (styles substring)))))"
>
> After typing `C-x d / TAB', I see this on master:
>
> x

More simply, even with -Q, 
(let ((file-name-handler-alist nil)
      (completion-styles '(substring))
      (default-directory "/"))
  (read-file-name ":"))

gives you a minibuffer containing "/"

Hitting ? will show all the possible completions, all of which (on your
system) contain a "/" as a suffix since they are directories.

Hitting TAB will make the minibuffer contain "//", with point in between
the two slashes.  You can then continue to type more characters
contained in the directory names to further narrow down the completions.

This is the behavior of the substring completion style.  When there's a
common substring between all the completions,
completion-substring-try-completion inserts that substring.  Since the
substring is a common suffix, it positions point before that common
suffix.

If there are any other completion styles before substring, this doesn't
happen.  e.g. with:

(let ((file-name-handler-alist nil)
      (completion-styles '(basic substring))
      (default-directory "/"))
  (read-file-name ":"))

Hitting TAB will do nothing.

To have only "substring" configured as a completion style implies you
want the behavior of the "substring" completion style, and only that
behavior.  You are indeed getting that behavior.  What's the problem?
substring has always behaved like this, so improved consistency in edge
cases like this one should not be a surprise.

Is there some problem with this behavior, some reason it doesn't work
right for you?  A more concrete complaint about what doesn't work would
be helpful.