GNU bug report logs - #22169
25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X

Previous Next

Full log

View this message in rfc822 format

From: Anders Lindgren <andlind <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 22169 <at> debbugs.gnu.org
Subject: bug#22169: 25.0.50; File name compiletion doesn't work with non-ASCII characters on OS X
Date: Tue, 15 Dec 2015 20:16:03 +0100

[Message part 1 (text/plain, inline)]

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


When you set file-name-coding-system to nil, Emacs uses
> default-file-name-system, which is utf-8, so it doesn't
> compose/decompose characters, and that's why you see what you see.
> IOW, using nil is a step backward.
>

I couldn't agree more!


What does this return:
>
>   M-: (file-name-all-completion "åäö" "/that/empty/directory/") RET
>

It returns nil.


Also, what is your value of completion-ignore-case?
>

It's nil.

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?

    -- Anders

[Message part 2 (text/html, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.