GNU bug report logs -
#22169
25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X
Previous Next
Reported by: Anders Lindgren <andlind <at> gmail.com>
Date: Mon, 14 Dec 2015 19:09:01 UTC
Severity: normal
Found in version 25.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> Date: Tue, 15 Dec 2015 20:16:03 +0100
> From: Anders Lindgren <andlind <at> gmail.com>
> Cc: 22169 <at> debbugs.gnu.org
>
> I think we should remove that, and leave behind an alias that uses
> utf-8-hfs, which is provided by Emacs. There's no reason to maintain
> 2 identical definitions.
>
> Sounds reasonable. The implementation is vastly different, so getting rid of
> one is definitively an improvement.
Can you write a patch to that effect, for emacs-25 branch?
> What does this return:
>
> M-: (file-name-all-completion "åäö" "/that/empty/directory/") RET
>
> It returns nil.
So this is the heart of the problem. I assume that if you do the same
with an ASCII first argument, the result is non-nil, yes?
Then the next step is to step with a debugger through
file_name_completion, and see why this returns nil instead of a list
of files that begin.
> Just out of curiosity -- how does `file-name-all-completions' work? Is the FILE
> argument encoded to decomposed form, is the file list converted to composed
> form, or is this handled by the comparison functions?
See dired.c:file_name_completion. In a nutshell, we do this:
. encode the file argument
. encode the directory argument and pass it to opendir
. loop calling readdir, and for each file name it returns:
. if the file name begins with the same characters as the encoded
file argument, then:
. decode the file name
. cons the decoded name onto the list to be returned
The above is for file-name-all-completions; for file-name-completion
the last step is more complicated, but we should understand the
file-name-all-completions case first.
When you step through the code, please pay attention to the encoded
file names. My guess is that somehow the call to scmp around line 500
fails, or maybe we don't count characters correctly in this case.
Thanks.
This bug report was last modified 9 years and 154 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.