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

[Eli Zaretskii]

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