GNU bug report logs -
#11339
24.1.50; read-{buffer,file-name}-completion-ignore-case fails on non-ascii
Previous Next
Reported by: Stephen Berman <stephen.berman <at> gmx.net>
Date: Wed, 25 Apr 2012 15:39:03 UTC
Severity: normal
Merged with 10211
Found in versions 24.0.92, 24.1.50, 27.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #55 received at 11339 <at> debbugs.gnu.org (full text, mbox):
> From: Stephen Berman <stephen.berman <at> gmx.net>
> Cc: stefan <at> marxist.se, 11339 <at> debbugs.gnu.org
> Date: Mon, 04 Nov 2019 19:02:15 +0100
>
> >> 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).
I'm sorry, but someone else will have to dig into this. I tried, but
got lost. I always do when I try to debug non-trivial issues with
completion, what with the endless ping-pong of calls from
minibuffer.el to minibuf.c and back, both directly and indirectly via
variables whose values are functions.
The best I could see (unless I'm mistaken) is that in the "C-x b" case
the second TAB sees that the string in the minibuffer is a possible
completion, and declares success; it doesn't call all-completions as
I'd expect. If this observation is correct, then relying on
try-completions in this case is what trips us, because try-completions
has special heuristics when the candidates are all identical but for
the letter-case, the result being that only one candidate is returned.
CC'ing Stefan who might have a better idea of what is going on here.
This bug report was last modified 5 years and 191 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.