[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: File name completion with non-ascii filenames

From: Niels Möller
Subject: Re: File name completion with non-ascii filenames
Date: 18 Dec 2001 12:44:18 +0100
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

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

At the start of file_name_completion, file was

$3 = (struct Lisp_String *) 0x3b5e24

and a little later, encoded_file was

$7 = (struct Lisp_String *) 0x3b5db4

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]