Michael Sperber writes:
I can reproduce the situation on a MULE XEmacs in an UTF-8 locale.
also breaks on a non-MULE XEmacs, but in a different way. Fixing it
there is harder.) The reason is that `default-process-coding-system' is
'undecided in the read direction, and UTF-8 fails to get detected.
This is what needs to get fixed. UTF-8 is easy to detect, and there's
really very little excuse for not detecting it.
In the current framework, this would require somebody studying Ben's
"new" (actually goes back to 2002 or so by now) detection algorithms
and tweaking them to produce UTF-8.
My suggestion is to align the coding system in
with the locale's coding system. Works for me.
You will definitely run into problems with TRAMP and EFS. Is your
patch in a place where you're not enforcing a coding system on those
extended file systems?
It's a general problem, too, because Unix file systems are not in any
locale. It's just user convention that any byte (even ASCII)
corresponds to a character. It's quite possible (and in Japan you'll
occasionally find these in the wild) to find servers with 3
directories encoded in EUC, UTF-8, and Shift JIS respectively for
It's unusual that any given user will see all of them though, and
their own system will generally be 99.44% consistent. You may as well
just do it as you suggest, though, because I don't have time to do it
right soon. (Actually, only Ben could probably do it very quickly.)
XEmacs-Beta mailing list