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

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: stefan@marxist.se,  11339@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