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

[Stephen Berman]

On Wed, 06 Nov 2019 18:58:36 +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 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'
>> >> 
[...]
>> 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.

So why do we have to rely on `try-completion' here?  Emacs built with
the patch below shows the behavior I want with `C-x b' using the above
recipe.  I assume that are bad side effects elsewhere, but I can't think
of any offhand.

Steve Berman

diff --git a/src/minibuf.c b/src/minibuf.c
index f6cf47f1f2..4faf2f856d 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -1777,9 +1777,7 @@ If FLAG is nil, invoke `try-completion'; if it is t, 
invoke
 `all-completions'; otherwise invoke `test-completion'.  */)
   (Lisp_Object string, Lisp_Object predicate, Lisp_Object flag)
 {
-  if (NILP (flag))
-    return Ftry_completion (string, Vbuffer_alist, predicate);
-  else if (EQ (flag, Qt))
+  if (EQ (flag, Qt))
     {
       Lisp_Object res = Fall_completions (string, Vbuffer_alist, predicate, 
Qnil);
       if (SCHARS (string) > 0)