Stephen J Turnbull <turnbull(a)sk.tsukuba.ac.jp> writes in xemacs-beta(a)xemacs.org:
>>>>> "sb" == SL Baur
<steve(a)xemacs.org> writes:
sb> Is it supposed to be EUC encoded Japanese?
sb> Opening directory:
sb> ¤½¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤¢¤ë¤¤¤Ï¥Ç¥£¥ì¥¯¥È¥ê¤Ï¤¢¤ê¤Þ¤»¤ó,
sb> /usr/users/steve/Mail/archives/
Yes. It says (in EUC-encoded Japanese) "There is no file or
directory
like that." Mark the region and hit it with `(decode-coding-region
(mark) (point) 'euc-jp)'.
There's supposed to be a process-coding-system variable in Mule
2.3,
but I don't think we've implemented it.
We've implemented it, but it's broken by default.
In a *shell* buffer:
$ ls fred
ls: fred: ¤½¤Î¤è¤¦¤Ê¥Õ¥¡¥¤¥ë¤¢¤ë¤¤¤Ï¥Ç¥£¥ì¥¯¥È¥ê¤Ï¤¢¤ê¤Þ¤»¤ó
$ ls fred
ls: fred: そのようなファイルあるいはディレクトリはありません
In between the two commands I did:
(set-buffer-process-coding-system 'euc-jp 'euc-jp)
One would guess it's a bit unreliable in localized contexts, and
useless in multilingual ones (eg, the Japanese Web, one language, a
Babel of encodings).
As Moriokasan is explaining to me.