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

From: Stephen Berman <[email-masked]>
Date: Wed, 18 Jun 2025 01:00:31 +0200

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

> Stephen Berman <[email-masked]> writes:
>
>> On Tue, 17 Jun 2025 10:59:56 -0400 Spencer Baugh <[email-masked]> wrote:
[...]
>>> 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.

Yes, I noted this upthread, where I pointed out that this differs from
the previous behavior, which is why I called it a regression
(https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-04/msg00884.html).

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

You may consider this an edge case, but it is proof that the substring
style has not "always behaved like this".  I don't recall that the goal
of "improved consistency in edge cases" was previously cited in this
thread; if it had been, I might have viewed the issue in a different
light, though I still find the current behavior problematic...

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

...to wit:

Before your change, when using substring style, typing `C-x d /us TAB
TAB' completes to "/usr/" and pops up the *Completions* buffer.  If I
want to change the input, e.g. to "/var/", I can type `M-DEL va TAB'.

After your change, when using substring style, typing `C-x d /us TAB
TAB' completes to "/usr//" and only after typing TAB a third time does
the *Completions* buffer pop up.  If I want to change the input, typing
`M-DEL' has no effect, though e.g. `C-f / va TAB' works (the minibuffer
then displays "~//usr//var/" with "~//usr/" in file-name-shadow face).
It works, but it's a bit more cumbersome than previously (an extra TAB
to get the *Completions* buffer) and visually confusing (at least given
familiarity with the previous behavior).

And again, with my patch (posted in
https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-04/msg01860.html)
I get the behavior and appearance I'm used to, and for my usage have
encountered no problems with it.  I ask you once again: please tell me
specifically what problems that patch causes.

Steve Berman