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

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

[Stephen Berman]

-1. cd /tmp; touch bäh bÄh bla
0. emacs -Q
1. M-x customize-option RET read-buffer-completion-ignore-case RET.
   Toggle to "on", set for the current session.
   M-x customize-option RET read-file-name-completion-ignore-case RET.
   Toggle to "on", set for the current session.
2. C-x C-f b TAB => *Completions* buffer contains, as expected: bla bÄh bäh.         
3. Visit files `bla', `bäh' and `bÄh', switch to buffer *scratch* and
   repeat step 2, replacing `C-x C-f' with `C-x b' => same results.
4. C-x C-f bä TAB => Emacs completes the input to "bäh".               
5. TAB => Emacs incorrectly reports: "[Sole completion]".                 
6. C-x C-f bÄ TAB => Emacs completes the input to "bÄh".
7. TAB => Emacs incorrectly reports: "[Sole completion]".                 
8. Switch to buffer *scratch* and repeat step 4-7, replacing `C-x C-f'
   with `C-x b' => same results.


In GNU Emacs 24.1.50.1 (i686-suse-linux-gnu, GTK+ Version 2.24.7)
 of 2012-04-18 on escher
Bzr revision: 107959 cyd@gnu.org-20120418070052-e6bm11h52qja62ue
Windowing system distributor `The X.Org Foundation', version 11.0.11004000
Configured using:
 `configure '--without-toolkit-scroll-bars' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=local
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

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

[Stephen Berman]

On Wed, 25 Apr 2012 17:37:38 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> -1. cd /tmp; touch bäh bÄh bla
> 0. emacs -Q
> 1. M-x customize-option RET read-buffer-completion-ignore-case RET.
>    Toggle to "on", set for the current session.
>    M-x customize-option RET read-file-name-completion-ignore-case RET.
>    Toggle to "on", set for the current session.
> 2. C-x C-f b TAB => *Completions* buffer contains, as expected: bla bÄh bäh.         
> 3. Visit files `bla', `bäh' and `bÄh', switch to buffer *scratch* and
>    repeat step 2, replacing `C-x C-f' with `C-x b' => same results.
> 4. C-x C-f bä TAB => Emacs completes the input to "bäh".               
> 5. TAB => Emacs incorrectly reports: "[Sole completion]".                 
> 6. C-x C-f bÄ TAB => Emacs completes the input to "bÄh".
> 7. TAB => Emacs incorrectly reports: "[Sole completion]".                 
> 8. Switch to buffer *scratch* and repeat step 4-7, replacing `C-x C-f'
>    with `C-x b' => same results.

This bug still exists in the current trunk.  I have an additional
observation, which I don't know if I just overlooked in my OP or if
there's been a code change since then that's responsible for this
observation: if only one of the files `bäh' and `bÄh' is being visited,
then `C-x b' completes correctly regardless of the case of the input;
i.e., if only `bÄh' is in a buffer `C-x b bä TAB' completes to it, and
likewise, if only `bäh' is in a buffer `C-x b bÄ TAB' completes to it.
But if only one of the files `bäh' and `bÄh' exists, `C-x C-f' still
only completes if the case of the input matches the case of the file
name, as above.

Here is part of the call chain of find-file:

find-file (files.el) -> find-file-read-args -> read-file-name
(minibuffer.el) -> read-file-name-default -> completing-read ->
read-file-name-internal -> completion-table-in-turn ->
completion--file-name-table -> completion-file-name-table ->
file-name-completion (dired.c) -> file_name_completion ->
fast_string_match_ignore_case (search.c) -> compile_pattern with argument
Vascii_canon_table

The argument Vascii_canon_table looks suspicious, but maybe it's already
been overridden earlier, though I don't see where; or maybe I just don't
understand its import here.  Anyway, the call chain of switch-to-buffer
is quite different:

switch-to-buffer (window.el) -> read-buffer-to-switch ->
internal-complete-buffer-except (minibuffer.el) -> internal-complete-buffer
(minibuf.c) -> (try-completion | all-completions | test-completion) ->
Fcompare_strings

(file_name_completion also calls Fcompare_strings later, but there's no
use of Vascii_canon_table there.)

I don't know how to debug this.

Steve Berman

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

[Stefan Kangas]

found 11339 27.0.50
thanks

Stephen Berman <stephen.berman@gmx.net> writes:

> -1. cd /tmp; touch bäh bÄh bla
> 0. emacs -Q
> 1. M-x customize-option RET read-buffer-completion-ignore-case RET.
>    Toggle to "on", set for the current session.
>    M-x customize-option RET read-file-name-completion-ignore-case RET.
>    Toggle to "on", set for the current session.
> 2. C-x C-f b TAB => *Completions* buffer contains, as expected: bla bÄh bäh.         
> 3. Visit files `bla', `bäh' and `bÄh', switch to buffer *scratch* and
>    repeat step 2, replacing `C-x C-f' with `C-x b' => same results.
> 4. C-x C-f bä TAB => Emacs completes the input to "bäh".               
> 5. TAB => Emacs incorrectly reports: "[Sole completion]".                 
> 6. C-x C-f bÄ TAB => Emacs completes the input to "bÄh".
> 7. TAB => Emacs incorrectly reports: "[Sole completion]".                 
> 8. Switch to buffer *scratch* and repeat step 4-7, replacing `C-x C-f'
>    with `C-x b' => same results.

I can reproduce this on current master using the simpler recipe:

0. emacs -Q
1. Evaluate (setq read-buffer-completion-ignore-case t)
2. C-x b bäh RET
3. C-x b bÄh RET
4. C-x b bä TAB TAB

Result: Completes to "bäh" on first TAB, and on second TAB [Sole
completion] is displayed in minibuffer.

Expected result: The "*Completion*" buffer is displayed.

Best regards,
Stefan Kangas

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

[Eli Zaretskii]

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 01 Nov 2019 20:57:30 +0100
> Cc: 11339@debbugs.gnu.org
> 
> > 0. emacs -Q
> > 1. M-x customize-option RET read-buffer-completion-ignore-case RET.
> >    Toggle to "on", set for the current session.
> >    M-x customize-option RET read-file-name-completion-ignore-case RET.
> >    Toggle to "on", set for the current session.
> > 2. C-x C-f b TAB => *Completions* buffer contains, as expected: bla bÄh bäh.         
> > 3. Visit files `bla', `bäh' and `bÄh', switch to buffer *scratch* and
> >    repeat step 2, replacing `C-x C-f' with `C-x b' => same results.
> > 4. C-x C-f bä TAB => Emacs completes the input to "bäh".               
> > 5. TAB => Emacs incorrectly reports: "[Sole completion]".                 
> > 6. C-x C-f bÄ TAB => Emacs completes the input to "bÄh".
> > 7. TAB => Emacs incorrectly reports: "[Sole completion]".                 
> > 8. Switch to buffer *scratch* and repeat step 4-7, replacing `C-x C-f'
> >    with `C-x b' => same results.
> 
> I can reproduce this on current master using the simpler recipe:
> 
> 0. emacs -Q
> 1. Evaluate (setq read-buffer-completion-ignore-case t)
> 2. C-x b bäh RET
> 3. C-x b bÄh RET
> 4. C-x b bä TAB TAB
> 
> Result: Completes to "bäh" on first TAB, and on second TAB [Sole
> completion] is displayed in minibuffer.
> 
> Expected result: The "*Completion*" buffer is displayed.

I think your expectations are incorrect in this case.  Try having
buffer names that differ (not in letter-case) in the 3rd letter.

What I see here is entirely expected and reasonable.  I see no bug.

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

[Stephen Berman]

On Fri, 01 Nov 2019 22:20:42 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stefan Kangas <stefan@marxist.se>
>> Date: Fri, 01 Nov 2019 20:57:30 +0100
>> Cc: 11339@debbugs.gnu.org
>> 
>> > 0. emacs -Q
>> > 1. M-x customize-option RET read-buffer-completion-ignore-case RET.
>> >    Toggle to "on", set for the current session.
>> >    M-x customize-option RET read-file-name-completion-ignore-case RET.
>> >    Toggle to "on", set for the current session.
>> > 2. C-x C-f b TAB => *Completions* buffer contains, as expected: bla bÄh
>> > bäh.
>> > 3. Visit files `bla', `bäh' and `bÄh', switch to buffer *scratch* and
>> >    repeat step 2, replacing `C-x C-f' with `C-x b' => same results.
>> > 4. C-x C-f bä TAB => Emacs completes the input to "bäh".               
>> > 5. TAB => Emacs incorrectly reports: "[Sole completion]".                 
>> > 6. C-x C-f bÄ TAB => Emacs completes the input to "bÄh".
>> > 7. TAB => Emacs incorrectly reports: "[Sole completion]".                 
>> > 8. Switch to buffer *scratch* and repeat step 4-7, replacing `C-x C-f'
>> >    with `C-x b' => same results.
>> 
>> I can reproduce this on current master using the simpler recipe:
>> 
>> 0. emacs -Q
>> 1. Evaluate (setq read-buffer-completion-ignore-case t)
>> 2. C-x b bäh RET
>> 3. C-x b bÄh RET
>> 4. C-x b bä TAB TAB
>> 
>> Result: Completes to "bäh" on first TAB, and on second TAB [Sole
>> completion] is displayed in minibuffer.
>> 
>> Expected result: The "*Completion*" buffer is displayed.
>
> I think your expectations are incorrect in this case.  Try having
> buffer names that differ (not in letter-case) in the 3rd letter.
>
> What I see here is entirely expected and reasonable.  I see no bug.

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

Steve Berman

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 Kangas <stefan@marxist.se>,  11339@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?

(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)

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

[Stephen Berman]

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

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

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: Sat, 02 Nov 2019 16:09:31 +0100
> 
> 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.

Yes, it was a bug, and a very old one: our case-insensitive comparison
of file names worked by bytes, which is only TRT for pure-ASCII
strings.

I hope I fixed this now, please try the latest master.

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

[Stephen Berman]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

On Sun, 03 Nov 2019 18:16:01 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: stefan@marxist.se,  11339@debbugs.gnu.org
>> Date: Sat, 02 Nov 2019 16:09:31 +0100
>>
>> 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.
>
> Yes, it was a bug, and a very old one: our case-insensitive comparison
> of file names worked by bytes, which is only TRT for pure-ASCII
> strings.
>
> I hope I fixed this now, please try the latest master.

I've now updated and, the above bug is now fixed; thanks.

However, there seems to be some unintended fallout:

0. emacs -Q
1. M-: (setq read-buffer-completion-ignore-case t read-file-name-completion-ignore-case t)
2. M-x cd RET RET => args-out-of-range error (backtrace attached)

This only seems to happen when trying to cd to a non-empty directory.
Judging by the backtrace, it also seems to be the same as bug#38056,
except that I cannot reproduce the error initially using the recipe of
that bug, but only with the one I gave above.  But once the error
occurs, all subsequent uses of TAB or RET for completion appear to raise
the error.

Steve Berman


[-- Attachment #2: backtrace --]
[-- Type: text/plain, Size: 5102 bytes --]

Debugger entered--Lisp error: (args-out-of-range ".mupdf.history" 12 2)
  file-name-completion("" "~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>))
  completion-file-name-table("~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>) nil)
  try-completion("~/" completion-file-name-table #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>))
  completion--file-name-table("~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>) nil)
  complete-with-action(nil completion--file-name-table "~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>))
  #f(compiled-function (table) #<bytecode 0xa35ad9>)(completion--file-name-table)
  completion--some(#f(compiled-function (table) #<bytecode 0xa35ad9>) (completion--embedded-envvar-table completion--file-name-table))
  read-file-name-internal("~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>) nil)
  locate-file-completion-table(("./") nil "~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>) nil)
  apply(locate-file-completion-table (("./") nil "~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>) nil))
  #f(compiled-function (&rest args2) #<bytecode 0xa2124d>)("~/" #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>) nil)
  try-completion("~/" #f(compiled-function (&rest args2) #<bytecode 0xa2124d>) #f(compiled-function (dir) #<bytecode 0x1fe7fb916111>))
  completion--complete-and-exit(27 29 exit-minibuffer #f(compiled-function () #<bytecode 0xa35a99>))
  completion-complete-and-exit(27 29 exit-minibuffer)
  minibuffer-complete-and-exit()
  funcall-interactively(minibuffer-complete-and-exit)
  call-interactively(minibuffer-complete-and-exit nil nil)
  command-execute(minibuffer-complete-and-exit)
  read-from-minibuffer("Change default directory: " "~/" (keymap (keymap (32)) keymap (10 . minibuffer-complete-and-exit) (13 . minibuffer-complete-and-exit) keymap (menu-bar keymap (minibuf "Minibuf" keymap (tab menu-item "Complete" minibuffer-complete :help "Complete as far as possible") (space menu-item "Complete Word" minibuffer-complete-word :help "Complete at most one word") (63 menu-item "List Completions" minibuffer-completion-help :help "Display all possible completions") "Minibuf")) (27 keymap (118 . switch-to-completions)) (prior . switch-to-completions) (63 . minibuffer-completion-help) (32 . minibuffer-complete-word) (9 . minibuffer-complete) keymap (menu-bar keymap (minibuf "Minibuf" keymap (previous menu-item "Previous History Item" previous-history-element :help "Put previous minibuffer history element in the min...") (next menu-item "Next History Item" next-history-element :help "Put next minibuffer history element in the minibuf...") (isearch-backward menu-item "Isearch History Backward" isearch-backward :help "Incrementally search minibuffer history backward") (isearch-forward menu-item "Isearch History Forward" isearch-forward :help "Incrementally search minibuffer history forward") (return menu-item "Enter" exit-minibuffer :key-sequence "\15" :help "Terminate input and exit minibuffer") (quit menu-item "Quit" abort-recursive-edit :help "Abort input and exit minibuffer") "Minibuf")) (10 . exit-minibuffer) (13 . exit-minibuffer) (7 . abort-recursive-edit) (C-tab . file-cache-minibuffer-complete) (9 . self-insert-command) (XF86Back . previous-history-element) (up . previous-line-or-history-element) (prior . previous-history-element) (XF86Forward . next-history-element) (down . next-line-or-history-element) (next . next-history-element) (27 keymap (60 . minibuffer-beginning-of-buffer) (114 . previous-matching-history-element) (115 . next-matching-history-element) (112 . previous-history-element) (110 . next-history-element))) nil file-name-history "~/" nil)
  completing-read-default("Change default directory: " read-file-name-internal file-directory-p t "~/" file-name-history "~/" nil)
  completing-read("Change default directory: " read-file-name-internal file-directory-p t "~/" file-name-history "~/")
  read-file-name-default("Change default directory: " "/home/steve/" "/home/steve/" t nil file-directory-p)
  read-file-name("Change default directory: " "/home/steve/" "/home/steve/" t nil file-directory-p)
  read-directory-name("Change default directory: " "/home/steve/" "/home/steve/" t)
  byte-code("\302\303C\211\304\305\306\307\310\6\7\6\7\"\311\"\312$\240\210\304\305\313\307\310\5!\314\"\312$\216\315\316\2\242\"\210\10\2045\0\317\320\321!!\2064\0..." [cd-path default-directory #f(compiled-function () #<bytecode 0x1fe7fb9160d9>) nil make-byte-code 0 "\302\303\301\242\"\210\300 \207" vconcat vector [remove-hook minibuffer-setup-hook] 3 "\301\302\300\242\"\207" [remove-hook minibuffer-setup-hook] add-hook minibuffer-setup-hook parse-colon-path getenv "CDPATH" "./" read-directory-name "Change default directory: " t] 10)
  call-interactively(cd record nil)
  command-execute(cd record)
  execute-extended-command(nil "cd" "cd")
  funcall-interactively(execute-extended-command nil "cd" "cd")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

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 14:39:25 +0100
> 
> > I hope I fixed this now, please try the latest master.
> 
> I've now updated and, the above bug is now fixed; thanks.

Thanks, I'm closing this bug.

> However, there seems to be some unintended fallout:
> 
> 0. emacs -Q
> 1. M-: (setq read-buffer-completion-ignore-case t read-file-name-completion-ignore-case t)
> 2. M-x cd RET RET => args-out-of-range error (backtrace attached)

This is bug#38056, which I just fixed.  It was caused by a thinko on
my part.

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

[Stephen Berman]

On Mon, 04 Nov 2019 14:39:25 +0100 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Sun, 03 Nov 2019 18:16:01 +0200 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Cc: stefan@marxist.se,  11339@debbugs.gnu.org
>>> Date: Sat, 02 Nov 2019 16:09:31 +0100
>>> 
>>> 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.
>>
>> Yes, it was a bug, and a very old one: our case-insensitive comparison
>> of file names worked by bytes, which is only TRT for pure-ASCII
>> strings.
>>
>> I hope I fixed this now, please try the latest master.
>
> I've now updated and, the above bug is now fixed; thanks.

I'd like to return to the bevahior I originally reported.  I think my
previous recapitulation of it was inaccurate, so here are explicit
recipes comparing current emacs-26 (representing the situation prior to
your fix) and current emacs-master (including your fix).

Add test files (crucially differing only in case and "asciiness"):

0. $ touch /tmp/{bah,bAh,bäh,bÄh}

Before your fix:

1. $ emacs-26 -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 [Sole completion]
6a. C-g C-x C-f /tmp/bÄ TAB
   => completes to /tmp/bÄh and after TAB displays [Sole completion]

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.

Steve Berman

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 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, so I
never looked at that (which explains why there's no change in that
behavior before and after my changes).  The changes I made are in code
that is used only for completing file names, which again explains why
completion of buffer names didn't change.

Now you are saying that buffer-name completion works incorrectly?  Or
are you saying something else?  I'd like to be sure what is it that
you consider in the need of fixing, and why.

Thanks.

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

[Stephen Berman]

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

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.

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)

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 Monnier <monnier@iro.umontreal.ca>,  stefan@marxist.se,
>   11339@debbugs.gnu.org
> Date: Thu, 07 Nov 2019 15:34:15 +0100
> 
> > 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?

Because that's how completion--do-completion was coded, I suppose.

> 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

Of course.  We cannot make such a change, I think.

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

[Stefan Monnier]

> 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.

I think the core of the bug is reproduced below:

    M-: (let ((completion-ignore-case t)) (try-completion "bah" '("bah" "bAh")))

this returns t instead of returning "bah".
Probably an error in the handling of `matchcount` in `try-completion`.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  11339@debbugs.gnu.org,  stefan@marxist.se
> Date: Thu, 07 Nov 2019 11:01:01 -0500
> 
> I think the core of the bug is reproduced below:
> 
>     M-: (let ((completion-ignore-case t)) (try-completion "bah" '("bah" "bAh")))
> 
> this returns t instead of returning "bah".
> Probably an error in the handling of `matchcount` in `try-completion`.

Are you sure?  I think the return value of t is expected, per these
comments in try-completion:

	      if (completion_ignore_case)
		{
		  /* If this is an exact match except for case,
		     use it as the best match rather than one that is not an
		     exact match.  This way, we get the case pattern
		     of the actual match.  */
		  if ((matchsize == SCHARS (eltstring)
		       && matchsize < SCHARS (bestmatch))
		      ||
		      /* If there is more than one exact match ignoring case,
			 and one of them is exact including case,
			 prefer that one.  */
		      /* If there is no exact match ignoring case,
			 prefer a match that does not change the case
			 of the input.  */

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

[Stefan Monnier]

>> I think the core of the bug is reproduced below:
>> 
>>     M-: (let ((completion-ignore-case t)) (try-completion "bah" '("bah" "bAh")))
>> 
>> this returns t instead of returning "bah".
>> Probably an error in the handling of `matchcount` in `try-completion`.
>
> Are you sure?

I think so, yes.

> I think the return value of t is expected, per these
> comments in try-completion:

I don't think so:

> 		  /* If this is an exact match except for case,
> 		     use it as the best match rather than one that is not an
> 		     exact match.  This way, we get the case pattern
> 		     of the actual match.  */

This says that (try-completion "bah" '("bAh" "bahfoo")) should return "bAh"

> 		      /* If there is more than one exact match ignoring case,
> 			 and one of them is exact including case,
> 			 prefer that one.  */

This says (try-completion "bah" '("bah" "bAh")) should return "bah" rather
than "bAh", which also agrees with I said above (it should not return t).

> 		      /* If there is no exact match ignoring case,
> 			 prefer a match that does not change the case
> 			 of the input.  */

This says that (try-completion "bah" '("bAhbar" "bahfoo")) should return
"bah" rather than "bAh".


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stephen.berman@gmx.net,  11339@debbugs.gnu.org,  stefan@marxist.se
> Date: Thu, 07 Nov 2019 11:27:50 -0500
> 
> >> I think the core of the bug is reproduced below:
> >> 
> >>     M-: (let ((completion-ignore-case t)) (try-completion "bah" '("bah" "bAh")))
> >> 
> >> this returns t instead of returning "bah".
> >> Probably an error in the handling of `matchcount` in `try-completion`.
> >
> > Are you sure?
> 
> I think so, yes.

The patch below fixes Stefan's simplified test case, but the original
problem is still unsolved: "C-x b ba TAB TAB" says "Sole completion".

What did I miss?

diff --git a/src/minibuf.c b/src/minibuf.c
index f6cf47f..2670211 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -1363,7 +1363,13 @@ DEFUN ("try-completion", Ftry_completion, Stry_completion, 2, 3, 0,
 		    bestmatch = eltstring;
 		}
 	      if (bestmatchsize != SCHARS (eltstring)
-		  || bestmatchsize != matchsize)
+		  || bestmatchsize != matchsize
+		  || (completion_ignore_case
+		      && !EQ (Fcompare_strings (bestmatch, zero,
+						make_fixnum (compare),
+						eltstring, zero,
+						make_fixnum (compare), Qnil),
+			      Qt)))
 		/* Don't count the same string multiple times.  */
 		matchcount += matchcount <= 1;
 	      bestmatchsize = matchsize;

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

[Stefan Monnier]

> The patch below fixes Stefan's simplified test case, but the original
> problem is still unsolved: "C-x b ba TAB TAB" says "Sole completion".
>
> What did I miss?

It still fails when you swap the two elements in the list :-(
I don't have time to dig into the code now, tho,


        Stefan


(ert-deftest try-completion-ignore-case ()
  (let ((completion-ignore-case t))
    (should (equal (try-completion "bar" '("bAr" "barfoo")) "bAr"))
    (should (equal (try-completion "bar" '("bArfoo" "barbaz")) "bar"))
    (should (equal (try-completion "bar" '("bArfoo" "barbaz"))
                   (try-completion "bar" '("barbaz" "bArfoo"))))
    ;; bug#11339
    (should (equal (try-completion "baz" '("baz" "bAz")) "baz")) ;And not `t'!
    (should (equal (try-completion "baz" '("bAz" "baz"))
                   (try-completion "baz" '("baz" "bAz"))))))

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stephen.berman@gmx.net,  11339@debbugs.gnu.org,  stefan@marxist.se
> Date: Fri, 08 Nov 2019 17:36:08 -0500
> 
> > The patch below fixes Stefan's simplified test case, but the original
> > problem is still unsolved: "C-x b ba TAB TAB" says "Sole completion".
> >
> > What did I miss?
> 
> It still fails when you swap the two elements in the list :-(
> I don't have time to dig into the code now, tho,

What about the below?  It passes all the tests, and also fixes the
original use case.

diff --git a/src/minibuf.c b/src/minibuf.c
index f6cf47f..1e87c50 100644
--- a/src/minibuf.c
+++ b/src/minibuf.c
@@ -1323,13 +1323,13 @@ DEFUN ("try-completion", Ftry_completion, Stry_completion, 2, 3, 0,
 	  else
 	    {
 	      compare = min (bestmatchsize, SCHARS (eltstring));
-	      tem = Fcompare_strings (bestmatch, zero,
-				      make_fixnum (compare),
-				      eltstring, zero,
-				      make_fixnum (compare),
+	      Lisp_Object lcompare = make_fixnum (compare);
+	      tem = Fcompare_strings (bestmatch, zero, lcompare,
+				      eltstring, zero, lcompare,
 				      completion_ignore_case ? Qt : Qnil);
 	      matchsize = EQ (tem, Qt) ? compare : eabs (XFIXNUM (tem)) - 1;
 
+	      Lisp_Object old_bestmatch = bestmatch;
 	      if (completion_ignore_case)
 		{
 		  /* If this is an exact match except for case,
@@ -1363,7 +1363,12 @@ DEFUN ("try-completion", Ftry_completion, Stry_completion, 2, 3, 0,
 		    bestmatch = eltstring;
 		}
 	      if (bestmatchsize != SCHARS (eltstring)
-		  || bestmatchsize != matchsize)
+		  || bestmatchsize != matchsize
+		  || (completion_ignore_case
+		      && !EQ (Fcompare_strings (old_bestmatch, zero, lcompare,
+						eltstring, zero, lcompare,
+						Qnil),
+			      Qt)))
 		/* Don't count the same string multiple times.  */
 		matchcount += matchcount <= 1;
 	      bestmatchsize = matchsize;

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

[Stephen Berman]

On Sat, 09 Nov 2019 11:20:12 +0200 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: stephen.berman@gmx.net,  11339@debbugs.gnu.org,  stefan@marxist.se
>> Date: Fri, 08 Nov 2019 17:36:08 -0500
>>
>> > The patch below fixes Stefan's simplified test case, but the original
>> > problem is still unsolved: "C-x b ba TAB TAB" says "Sole completion".
>> >
>> > What did I miss?
>>
>> It still fails when you swap the two elements in the list :-(
>> I don't have time to dig into the code now, tho,
>
> What about the below?  It passes all the tests, and also fixes the
> original use case.

I confirm it makes completion with `C-x b' work the way I want when case
is ignored, so I am in favor of installing it.  Thanks.

Steve Berman

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

[Stefan Monnier]

> What about the below?  It passes all the tests, and also fixes the
> original use case.

Sounds good.  I have the impression that I was the original author of
that "early exit" optimization (or at least some of it), but my brain
must be decaying because I have a hard time understanding the code.
I also wonder if it's really worth the effort (of the optimization,
I mean).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stephen.berman@gmx.net,  11339@debbugs.gnu.org,  stefan@marxist.se
> Date: Sat, 09 Nov 2019 13:24:06 -0500
> 
> > What about the below?  It passes all the tests, and also fixes the
> > original use case.
> 
> Sounds good.

Thanks, installed.

> I have the impression that I was the original author of that "early
> exit" optimization (or at least some of it), but my brain must be
> decaying because I have a hard time understanding the code.  I also
> wonder if it's really worth the effort (of the optimization, I
> mean).

AFAICT, you were the author of the "don't count the same string more
than once" fragment.

I'm closing the bug report.