bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#11339: 24.1.50; read-{buffer,file-name}-completion-ignore-case fails


From: Stephen Berman
Subject: bug#11339: 24.1.50; read-{buffer,file-name}-completion-ignore-case fails on non-ascii
Date: Mon, 04 Nov 2019 19:02:15 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

On Mon, 04 Nov 2019 19:12:03 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: stefan@marxist.se,  11339@debbugs.gnu.org
>> Date: Mon, 04 Nov 2019 17:22:30 +0100
>> 
>> After your fix:
>> 
>> 1. $ emacs-master -Q  --eval '(setq read-buffer-completion-ignore-case 
>> tread-file-name-completion-ignore-case t)' /tmp/{bah,bAh,bäh,bÄh}
>> (*Buffer List* show the buffers bah,bAh,bäh,bÄh)
>> 2. C-x b *scratch*
>> 3a. C-x b ba TAB
>>    => completes to bah and after TAB displays [Sole completion]
>> 3b. C-g C-x b bA TAB
>>    => completes to bAh and after TAB displays [Sole completion]
>> 4a. C-g C-x b bä TAB
>>    => completes to bäh and after TAB displays [Sole completion]
>> 4b. C-g C-x b bÄ TAB
>>    => completes to bÄh and after TAB displays [Sole completion]
>> 5a. C-g C-x C-f /tmp/ba TAB
>>    => completes to bah and after TAB displays [Complete, but not unique]
>>       and *Completions* pops up showing `bAh' and `bah'
>> 5b. C-g C-x C-f /tmp/bA TAB
>>    => completes to bAh and after TAB displays [Complete, but not unique]
>>       and *Completions* pops up showing `bAh' and `bah'
>> 6a. C-g C-x C-f /tmp/bä TAB
>>    => completes to /tmp/bäh and after TAB displays [Complete, but not unique]
>>       and *Completions* pops up showing `bAh' and `bah'
>> 6a. C-g C-x C-f /tmp/bÄ TAB
>>    => completes to /tmp/bÄh and after TAB displays [Complete, but not unique]
>>       and *Completions* pops up showing `bAh' and `bah'
>> 
>> So, before your fix file name completion involving non-ASCII strings
>> behaved the same as buffer name completion involving both ASCII-only and
>> non-ASCII strings, but file name completion involving ASCII-only strings
>> differed.  Now, after your fix, file name completion involving non-ASCII
>> strings works the same as file name completion involving ASCII-only
>> strings did before your fix and still does after, but all the cases of
>> file name completion differ from the corresponding cases of buffer name
>> completion.  I would prefer buffer name completion to work the way file
>> name completion uniformly works after your fix.
>
> "You are in a maze of twisty little passages, all alike."
>
> (I'm confused by a dozen of similar examples which don't say which
> result is deemed to be correct and which isn't.)
>
> Previously, you said that buffer-name completion works correctly, 

I don't think so.  In my OP of this bug I reported the results of `C-x
b' as incorrect (step 8 of the recipe there).  In my followup a year
later, I reiterated that the "bug still exists" but added a different
observation of correct behavior involving `C-x b' but incorrect behavior
involving `C-x C-f'.  After Stefan Kangas's post revisiting this bug,
which only looked at the `C-x b' behavior of my OP, you implied the
behavior is correct and said you see no bug, to which I replied with
what I intended to be a clarification of my OP, but it seems to have
confused you; my followup to that unfortunately seems to have added to
the confusion concerning the behavior of `C-x b', for which I apologize.
But I hope and think my last reply quoted above is clear: "all the cases
of file name completion differ from the corresponding cases of buffer
name completion. I would prefer buffer name completion to work the way
file name completion uniformly works after your fix."  To phrase it in
terms of correctness: the results of `C-x b' in steps 3-4 quoted above
are incorrect; they should be the same as the results of `C-x C-f' in
steps 5-6, which are correct (IMO).

Steve Berman





reply via email to

[Prev in Thread] Current Thread [Next in Thread]