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: Stephen Berman <stephen.berman <at> gmx.net>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 77718 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: bug#77718: 31.0.50; completion styles substring and flex are broken
Date: Wed, 18 Jun 2025 14:01:54 +0200

[Message part 1 (text/plain, inline)]

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.

Steve Berman

[Message part 2 (text/x-patch, attachment)]

Previous Next

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