bug in file-name-coding-system detection [was: font-lock-fontify-* ...]

[Stephen J. Turnbull]

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