GNU bug report logs - #79265
[PATCH] Treat point more consistently in PCM completion

Previous Next

Package: emacs;

Reported by: Spencer Baugh <sbaugh <at> janestreet.com>

Date: Mon, 18 Aug 2025 18:54:01 UTC

Severity: normal

Tags: patch

Done: Dmitry Gutov <dmitry <at> gutov.dev>

Full log


View this message in rfc822 format

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79265 <at> debbugs.gnu.org
Subject: bug#79265: [PATCH] Treat point more consistently in PCM completion, [PATCH] Treat point more consistently in PCM completion
Date: Thu, 21 Aug 2025 15:29:21 -0400
Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> [ Sorry for the delay reviewing this patch (and others, still waiting).
>   I still have rather spotty access to my keyboard, tho things should
>   slowly return to normal over the next two weeks.  ]

No worries, thanks for responding to this, to save me from my own buggy
change :)

>> From: Spencer Baugh <sbaugh <at> janestreet.com>
>> Date: Wed, 20 Aug 2025 13:23:34 -0400
>> Subject: [PATCH] Avoid duplicating strings in pcm--merge-completions
>>
>> Make completion-pcm--merge-completions operate only on the text
>> matched by the wildcards, instead of also the text in between
>> the wildcards.  This improves performance and simplifies the
>> code by removing the need for the previous mutable variable
>> "fixed".
>>
>> * lisp/minibuffer.el (completion-pcm--merge-completions):
>> Operate only on text matched by wildcards. (bug#79265)
>
> Could we have a regression test for this change?
> Or is it supposed to make no difference to behavior?

It's supposed to make no difference to behavior...

>> -            (while (setq next (match-end i))
>> -              (push (substring str last next) chopped)
>> -              (setq last next)
>> +            (while (setq next (match-string i str))
>> +              (push next chopped)
>
> IIUC this means that when `completion-ignore-case` is t we will keep the
> capitalization typed by the user rather than adjust it based on the
> completion candidates.
>
> E.g.
>
>     (let ((completion-ignore-case t))
>       (completion-pcm--merge-completions '("ABC" "ABD") '("a")))
>
> will complete "a" to "aB" rather than to "AB".
>
> See commit 681e0e7c02c4f8ff6d316c8c24001106cb847023 (which should have
> come with a regression test, obviously).

...except, you're right, of course it does cause this issue.  Thanks for catching this.

I'll write a test for this and try to find a further change to the code
which retains the improvement in clarity while still fixing this issue.

It should work to just arbitrarily take the capitalization from the
first completion in the list, I think, right?  That also will make
things more consistent, I think?




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.