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
Message #157 received at 77718 <at> debbugs.gnu.org (full text, mbox):
Stephen Berman via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:
> On Wed, 18 Jun 2025 01:00:31 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
>
>> 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:
>> [...]
>>> 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.
>> [...]
>>> 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.
>
> Assuming the current behavior of substring completion in master is not a
> bug/regression but the intended "improved consistency", I would like to
> propose a different patch (attached) to make the completion behavior
> conditional on a user option, defaulting to the current behavior in
> master.
Can we please avoid adding absurd user options like
`completion-/-not-common-suffix'? The completion machinery is already
complex with many options. Adding options for minor details does not
seem like a good direction.
Daniel
This bug report was last modified 10 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.