Mule bugs: misidentification (Latin-1 vs. Chinese), revert issues
Stephen J. Turnbull
stephen at xemacs.org
Mon Jan 14 13:58:46 EST 2008
Aidan Kehoe writes:
> On your original question; it's laughably unlikely (outside of
> Cygwin, where this code is not used) that ls will output file names
> in a coding system that doesn't reflect the octets stored in the
> directory entries.
Well, no, it's not funny at all in Japan where I know of servers
running in EUC or UTF-8 but handle Shift-JIS stores. I wouldn't be
surprised if similar issues arise with respect to KOI-8 and Big5.
> And on OS X
> file-name-coding-system (and relatedly, the 'file-name coding system alias)
> is unconditionally UTF-8, independent of the locale coding system.
This is a good heuristic, since the most popular file system on OS X
is HFS+, which does try to enforce UTF-8 file names.
> I would suggest binding coding-system-for-read to 'file-name, not
> (get-coding-system-from-locale (current-locale)) .
Yes, that's an excellent idea; it give the user enough control to deal
with the unusual cases described above.
More information about the XEmacs-Beta