Re: File name completion with non-ascii filenames

[Niels Möller]

Richard Stallman <address@hidden> writes:

>     Next I press TAB. The minibuffer changes to
> 
>        "Find file: ~/private/sonja/fö"
> 
> This certainly seems like a bug, but if we can't see it fail,
> we would have trouble debugging it.  Can you please try to
> debug it?  Try stepping through file_name_completion.

Ok, I started emacs with -q --no-site-file -nw (as things went bad the
last time I tried to debug an X program running the debugger under X),
and used set-input-mode to make it accept latin-1-input. Then I
attached gdb to the processed, put a break point on
file_name_completion, and started to look around. I also sourced
emacs-21.1/src/.gdbinit.

At the start of file_name_completion, file was

$3 = (struct Lisp_String *) 0x3b5e24
"f\201\366r"

and a little later, encoded_file was

$7 = (struct Lisp_String *) 0x3b5db4
"f\366r"

So far so good. The directory-reading loop picks up some matching
files. First "f\366r\344ldrar-och-barn.txt", and it sets bestmatchsize
to 22. Next, it picks up "f\366rord.tex", and now bestmatchsize is
reduced to 2. It should probably be 3?

The loop goes on, some more matching files are found, and
bestmatchsize stays at 2.

At the end at the function, Fsubstring is called with bestmatchsize as
the TO argument, giving "f\366" (should have been "f\366r"), and then
DECODE_FILE, giving "f\366".

I start over again, get to the file "f\366rord.tex", and try to see
where bestmatchsize=2 comes from. It's returned by the call to scmp,

  file_name_completion, about line 640 in dired.c:

            {
              compare = min (bestmatchsize, len);
              p1 = XSTRING (bestmatch)->data;
              p2 = (unsigned char *) dp->d_name;
!             matchsize = scmp(p1, p2, compare);
              if (matchsize < 0)
                matchsize = compare;

Stepping into scmp, it first correctly computes match = 3, but then it
gets into multibyte-handling:

    {
      int match = len - l;  /* !Here match is assigned 3 */

      /* Now *--S1 is the unmatching byte.  If it is in the middle of
         multi-byte form, we must say that the multi-byte character
         there doesn't match.  */
      while (match && *--s1 >= 0xA0) match--;
      /* ! But now it's only 2 */
      return match;
    }

So the bug is that scmp assumes that its argument are multibyte MULE
strings, and file_name_completion calls it with arguments that are
latin-1 strings.

Regards,
/Niels