GNU bug report logs - #47127
27.1; ido file completion sorting should respect ido-case-fold, maybe?

Previous Next

Package: emacs;

Reported by: "Ryan C. Thompson" <rct <at> thompsonclan.org>

Date: Sat, 13 Mar 2021 21:58:02 UTC

Severity: normal

Found in version 27.1

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


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

From: "Ryan C. Thompson" <rct <at> thompsonclan.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 47127 <at> debbugs.gnu.org
Subject: Re: bug#47127: 27.1; ido file completion sorting should respect
 ido-case-fold, maybe?
Date: Fri, 24 Jun 2022 09:58:17 -0400
On 6/24/22 8:56 AM, Lars Ingebrigtsen wrote:
> "Ryan C. Thompson" <rct <at> thompsonclan.org> writes:
>
>> ;; Returns nil, as expected
>> (let ((ido-case-fold nil))
>>    (ido-file-lessp "a" "B"))
>>
>> ;; Should return t, but currently returns nil
>> (let ((ido-case-fold t))
>>    (ido-file-lessp "a" "B"))
>>
>> ;; Should still return t because case is the only difference
>> (let ((ido-case-fold t))
>>    (ido-file-lessp "A" "a"))
>>
>> At least, this is what makes sense to me.
> I think this function should respect ido-case-fold, but special-casing
> equal strings here seems pretty unnatural to me -- if you want to ignore
> case, you want to ignore case.
>
> So I've now made this change in Emacs 29.

I don't understand why it's a problem to special-case strings that are 
equal after case folding. If I understand correctly, when case folding 
is enabled, then the sort order of such strings is arbitrary. If so, why 
not choose a consistent way to break the tie? For instance, if I know 
that "A.txt" will always sort before "a.txt" and both are present in the 
folder, if the order is consistent then I can always type "a.txt C-s 
RET" to select "a.txt", because I know it will be the 2nd matching 
choice. The result is a sort order that is correct when ignoring case 
while also being completely predictable even for strings differing only 
in case.

Regardless, I don't feel strongly about this, and I can always apply 
advice similar to the above for my own use, so if you're not convinced 
by the above argument, feel free to leave it as is. (Also, perhaps it 
already works this way incidentally, if the list of files is returned in 
lexical order and the sorting is stable.)






This bug report was last modified 3 years and 28 days ago.

Previous Next


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