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
Message #50 received at submit <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> . 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
My guess from the symptoms is that utf-8-nfd doesn't actually
bother to make any attempt to convert to decomposed form when
encoding, since in *most* cases e.g. for opening a file, the
underlying filesystem will take care of this automatically.
This is backed up by the fact that, looking at the code, it
apparently has a post-read-conversion but no matching
pre-write-conversion.
Anders Lindgren writes:
> I tried setting it to nil. This made completion work. However,
> the letters are presented in decomposed form, so that pressing
> backspace first converts "å" to "a", a second backspace
> deletes the "a" -- this is not how we would like to present
> file names to users.
Why? That _is_, for better or worse, the filename on the
disk. On a non-OSX system, someone might actually have such a
filename, distinct from the composed one.
For that matter, what happens if an OSX user saves or opens a
file on a non-HFS filesystem? Can Emacs handle the concept of
different filesystems having different encodings?
Ultimately, this isn't really an encoding - it is a destructive
folding operation performed by the filesystem (the same as if,
say, some filesystem stored filenames in all uppercase), and
we've decided, for some reason, that we want the filenames back
in what we've judged to be more likely to be the original form.
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.