GNU bug report logs - #11339
24.1.50; read-{buffer,file-name}-completion-ignore-case fails on non-ascii

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11339 <at> debbugs.gnu.org, stefan <at> marxist.se
Subject: bug#11339: 24.1.50; read-{buffer,file-name}-completion-ignore-case fails on non-ascii
Date: Mon, 04 Nov 2019 14:39:25 +0100

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

On Sun, 03 Nov 2019 18:16:01 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: stefan <at> marxist.se,  11339 <at> debbugs.gnu.org
>> Date: Sat, 02 Nov 2019 16:09:31 +0100
>>
>> Concerning my followup to my OP, that involved another difference I
>> observed in completion behavior between buffer names and file names with
>> non-ASCII characters when *-completion-ignore-case is non-nil, and
>> that's what the recipe above shows in more detail than in my followup,
>> which didn't explicitly contrast the behavior with ASCII-only characters
>> (the above recipe also uses names that differ beyond the case
>> differences, to avoid the question of expectations where only case
>> differs): with buffer names, all completions are shown regardless of the
>> case of the input, but with file names, completion is done according to
>> the case of the input, i.e. read-file-name-completion-ignore-case
>> appears to have no effect (again, only when the names contain non-ASCII
>> characters).  This seems to be a clear bug.
>
> Yes, it was a bug, and a very old one: our case-insensitive comparison
> of file names worked by bytes, which is only TRT for pure-ASCII
> strings.
>
> I hope I fixed this now, please try the latest master.

I've now updated and, the above bug is now fixed; thanks.

However, there seems to be some unintended fallout:

0. emacs -Q
1. M-: (setq read-buffer-completion-ignore-case t read-file-name-completion-ignore-case t)
2. M-x cd RET RET => args-out-of-range error (backtrace attached)

This only seems to happen when trying to cd to a non-empty directory.
Judging by the backtrace, it also seems to be the same as bug#38056,
except that I cannot reproduce the error initially using the recipe of
that bug, but only with the one I gave above.  But once the error
occurs, all subsequent uses of TAB or RET for completion appear to raise
the error.

Steve Berman

[Message part 2 (text/plain, attachment)]

Previous Next

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