GNU bug report logs - #79377
[PATCH] Return case common to all completions in try-completion

Previous Next

To reply to this bug, email your comments to 79377 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Return case common to all completions in try-completion
Date: Wed, 03 Sep 2025 09:07:30 -0400

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

Tags: patch


There are a few bugs with completion-pcm-try-completion not returning
text whose case matches the completions, even when the case is identical
between all the completions.  I added some tests covering them.

Ultimately, these bugs are nicely fixed by an improvement to
Ftry_completion; the removed conditional (and its associated comment) in
Ftry_completion didn't actually improve behavior, but instead made case
behavior worse.  I believe the bad behavior which this conditional was
originally attempting to stop was removed at some point by other
enhancements to Ftry_completion's completion-ignore-case behavior, so
the conditional isn't necessary anymore.

In GNU Emacs 30.1.90 (build 43, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2025-09-03 built on
 igm-qws-u22796a
Repository revision: 8a831d9c110ea4dd349444de8f99d7cee10c5273
Repository branch: emacs-30
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Rocky Linux 8.10 (Green Obsidian)

Configured using:
 'configure --with-x-toolkit=lucid --without-gpm --without-gconf
 --without-selinux --without-imagemagick --with-modules --with-gif=no
 --with-cairo --with-rsvg --without-compress-install --with-tree-sitter
 --with-native-compilation=aot
 PKG_CONFIG_PATH=/usr/local/home/garnish/libtree-sitter/0.22.6-1/lib/pkgconfig/'

[0001-Return-case-common-to-all-completions-in-try-complet.patch (text/patch, attachment)]

Message #8 received at 79377 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79377 <at> debbugs.gnu.org
Subject: Re: bug#79377: [PATCH] Return case common to all completions in
 try-completion
Date: Wed, 03 Sep 2025 09:44:45 -0400

> Ultimately, these bugs are nicely fixed by an improvement to
> Ftry_completion; the removed conditional (and its associated comment) in
> Ftry_completion didn't actually improve behavior, but instead made case
> behavior worse.  I believe the bad behavior which this conditional was
> originally attempting to stop was removed at some point by other
> enhancements to Ftry_completion's completion-ignore-case behavior, so
> the conditional isn't necessary anymore.

Hmm... the way I read the code (and its comment), this conditional does
very purposefully what you don't want.  I don't know why that was
considered desirable, so I tend to agree with you here, but I don't
know what you think was the "bad behavior which this conditional was
originally attempting to stop".


        Stefan

Message #11 received at 79377 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Dmitry Gutov <dmitry <at> gutov.dev>, 79377 <at> debbugs.gnu.org
Subject: Re: bug#79377: [PATCH] Return case common to all completions in
 try-completion
Date: Wed, 03 Sep 2025 12:48:49 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> Ultimately, these bugs are nicely fixed by an improvement to
>> Ftry_completion; the removed conditional (and its associated comment) in
>> Ftry_completion didn't actually improve behavior, but instead made case
>> behavior worse.  I believe the bad behavior which this conditional was
>> originally attempting to stop was removed at some point by other
>> enhancements to Ftry_completion's completion-ignore-case behavior, so
>> the conditional isn't necessary anymore.
>
> Hmm... the way I read the code (and its comment), this conditional does
> very purposefully what you don't want.  I don't know why that was
> considered desirable, so I tend to agree with you here, but I don't
> know what you think was the "bad behavior which this conditional was
> originally attempting to stop".

Ah, you're right.  I just read through the history of this function and
I can't see anything like that.  So... yeah, I guess the "bad behavior
which this conditional was originally attempting to stop" is exactly the
behavior I want.  Well, 34 years after it was originally written, I do
think deleting this conditional is better :)

Previous Next

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