GNU bug report logs - #77718
31.0.50; completion styles substring and flex are broken

Previous Next

Full log

View this message in rfc822 format

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: 77718 <at> debbugs.gnu.org
Cc: sbaugh <at> janestreet.com, eliz <at> gnu.org, stephen.berman <at> gmx.net, monnier <at> iro.umontreal.ca
Subject: bug#77718: 31.0.50; completion styles substring and flex are broken
Date: Wed, 18 Jun 2025 14:17:43 +0200

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.