bug in file-name-coding-system detection [was: font-lock-fontify-* ...]
Stephen J. Turnbull
stephen at xemacs.org
Tue Jan 9 22:12:24 EST 2007
Aidan Kehoe writes:
> Unless your ~/.xemacs/init.el already handles what coding system file names
> are in, you probably don’t want to remove the package. The change I made
> that provoked the new behaviour on your machine added support for sniffing
> what encoding file names were in, which should be beneficial for you.
Excuse me? "Sniffing the encoding of a file *name*"? Surely you mean
your patch for "determining the system's file-name-coding-system"?
And this is in the *locale* package? Aidan, that's wrong; the locale
package was intended to be data-only, with only the code needed to
load the data. This kind of basic functionality should be in
mule-base, or even core.
And now I know who to blame for the fact that suddenly I can no longer
reliably read Japanese file names in UTF-8. (Part of the blame goes
to Mac OS X, which doesn't set the locale, but has a whole separate
set of internationalization functions---this confuses all Unix
software, of course, even ls in an Apple Terminal.)
The point is (as I've said before) that the POSIX locale is *not* a
sufficiently reliable way to determine file-name-coding-system. The
user can set the locale but at least on Mac OS X HFS+ that doesn't
affect the file system's encoding, it stays canonically decomposed
UTF-8 (and will barf on, eg, ISO 8859/2). On the other hand, on most
Unix file systems, a file name is simply a binary blob, that happens
to be human readable most of the time.
Also, something that sniffs file-name-coding-system should definitely
*not* affect user interface.
Please fix this. "Fix" includes documentation on how to turn it off,
More information about the XEmacs-Beta