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

Previous Next

Full log

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

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: Re: bug#11339: 24.1.50;
 read-{buffer,file-name}-completion-ignore-case fails on non-ascii
Date: Sat, 02 Nov 2019 16:09:31 +0100

On Sat, 02 Nov 2019 09:11:54 +0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: Stefan Kangas <stefan <at> marxist.se>,  11339 <at> debbugs.gnu.org
>> Date: Fri, 01 Nov 2019 23:37:54 +0100
>> 
>> I think the expectation I had about the variables
>> read-{buffer,file-name}-completion-ignore-case was that they allow
>> getting information with less effort, in that by typing either a lower
>> or an upper case character, you would see names that have either or both
>> cases.  And that is apparently what I (thought I) had experienced with
>> ASCII characters but not with non-ASCII characters, which I assume is
>> what prompted my OP.  Unfortunately, the recipe in my OP did not include
>> the `bah' and `bAh' cases as a sanity check, and now I find the same
>> behavior with them as reported above for the non-ASCII cases.  So it
>> seems either the handling of the ASCII cases has changed since my OP, or
>> I was mistaken at the time in thinking there was a difference.  I also
>> followed up my OP more than a year later, reporting that the bug still
>> existed and adding a further observation
>> (https://lists.gnu.org/archive/html/bug-gnu-emacs/2013-07/msg00340.html).
>> And regarding the latter, on recent master that does indeed show a
>> difference between ASCII and non-ASCII characters:
>> 
>> 0. touch /tmp/{bah,bAG,bäh,bÄg}
>> 1. emacs-master -Q --eval '(setq read-buffer-completion-ignore-case t read-file-name-completion-ignore-case t)' /tmp/{bah,bAg,bäh,bÄg}
>> 2. C-x b *scratch*
>> 3a. C-x b ba TAB
>>    => *Completions* pops up showing `bAg' and `bah'
>> 3b. C-x b bA TAB
>>    => *Completions* pops up showing `bAg' and `bah'
>> 4a. C-g C-x b bä TAB
>>    => *Completions* pops up showing `bÄg' and `bäh'
>> 4b. C-g C-x b bÄ TAB
>>    => *Completions* pops up showing `bÄg' and `bäh'
>> 5a. C-g C-x C-f /tmp/ba TAB
>>    => *Completions* pops up showing `bAg' and `bah'
>> 5b. C-g C-x C-f /tmp/bA TAB
>>    => *Completions* pops up showing `bAg' and `bah'
>> 6a. C-g C-x C-f /tmp/bä TAB
>>   => completes to /tmp/bäh
>> 6a. C-g C-x C-f /tmp/bÄ TAB
>>   => completes to /tmp/bÄg
>
> I'm confused wrt what you are saying here.  Your original report
> seemed to be about read-buffer-completion-ignore-case not working as
> expected with non-ASCII buffer names.  Are you now saying that the
> problem is actually with read-file-name-completion-ignore-case
> instead?  Or are you saying something else?

There are two issues: what was reported in my OP, and what was in my
followup more than a year later.

Concerning my OP, I reported what I took to be a bug in how completion
works on names containing non-ASCII characters when either
read-buffer-completion-ignore-case or
read-file-name-completion-ignore-case (or both) are non-nil.  My
expectation was that with e.g. the names `bäh' and `bÄh' typing either
`bä' or `bÄ' and then TAB should shows both names (for both buffer and
file name completion), but in both cases TAB only completed to `bäh' and
`bÄh', respectively.  Since the OP explicitly says this is a problem
with non-ASCII characters, I assume I thought that with ASCII-only
characters the behavior was different, i.e., with names `bah' and `bAh',
typing either `ba' or `bA' followed by TAB did show both names as
completions.  However, what I now see is that only the respective
completions `bah' and `bAh' are shown after TAB.  I usually try to test
what I consider to be all relevant cases before making a bug report, and
if I did so in this case, that means completion with ASCII-only
characters has changed since my OP, and if so, this seems to me to be a
regression, since I had regarded similar behavior with non-ASCII
characters as bug; but since I failed to include the ASCII-only cases in
the bug report, perhaps I was mistaken and the ASCII-only cases were
always like they are now.  In any case, though the current behavior is
consistent between ASCII-only and non-ASCII characters (unlike what I
thought was the case when I made my OP), so I suppose it may be
considered not to be a bug, it is not what I would prefer.

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.

> (May I suggest in the future to state explicitly the conclusion(s)
> from the evidence you present, so as to make the communications more
> efficient?  TIA)

I'll try to, and I hope the above is now clear enough.

Steve Berman

Previous Next

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