GNU bug report logs -
#77718
31.0.50; completion styles substring and flex are broken
Previous Next
Full log
Message #151 received at 77718 <at> debbugs.gnu.org (full text, mbox):
On Tue, 17 Jun 2025 15:26:36 -0400 Spencer Baugh <sbaugh <at> janestreet.com> wrote:
> Stephen Berman <stephen.berman <at> gmx.net> writes:
>
>> On Tue, 17 Jun 2025 10:59:56 -0400 Spencer Baugh <sbaugh <at> janestreet.com> 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
This bug report was last modified today.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.