GNU bug report logs -
#77718
31.0.50; completion styles substring and flex are broken
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Thu, 10 Apr 2025 22:23:02 UTC
Severity: normal
Found in version 31.0.50
Done: Stefan Monnier <monnier <at> iro.umontreal.ca>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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 9 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.