Re: coding-system lossage with eterm
Stephen J. Turnbull wrote:
A little bit of experimentation shows that setting the process
coding
system to 'iso-2022-jp gives nice Japanese, with the same ol' ugly
staircase. 'undecided-unix gives nice left-justified moji-bake, and
'iso-2022-unix gives left-justified Japanese. 'undecided-dos gives
staircase.
Previously, I got the same results for undecided-unix (left-justified
mojibake), which I though was odd. However, I've tried it again and
now undecided-unix gives me left-justified Japanese, which is what I
would expect.
Glynn> Actually, I suspect that it's more likely
coding-system
Glynn> related.
It's hard to see how Mule could guess in advance that it's going to be
seeing EUC-JP vs some other 8-bit ISO-2022-compatible encoding. So
it's not surprising it gets the Japanese wrong. What seems to have
happened is that for the process coding system we're defaulting to
*-dos, while the file coding systems are defaulted (usually correctly)
by the build environment. I would guess somebody just overlooked the
process coding system in the coding system overhaul.
Starting eterm and evaluating:
(process-coding-system (get-buffer-process (current-buffer)))
produces the result:
(#<coding_system undecided> . #<coding_system binary>)
Presumably the ^M results in the coding system being assumed to be
<something>-dos.
Glynn> Any suggestions as to what coding system it should set?
Or
Glynn> should it be a defcustom? In which case what would the
Glynn> default be?
The default should be a defcustom, probably defaulted to ISO-8859-1.
When possible, the coding system should be set according to LANG.
(Steve, were you running with LANG=ja or not? I gotta get some sleep,
so I'm not going to experiment further....)
I would guess that undecided-unix would be the right thing, _if_ it
worked consistently.
Could people report what results they get from the following:
M-: (setq process-coding-system-alist '((".*" . undecided-unix))) RET
M-x term RET RET
cat /usr/local/lib/xemacs/packages/etc/mule-doc/ISO2022.jp
C-c C-j
M-: (process-coding-system (get-buffer-process (current-buffer))) RET
--
Glynn Clements <glynn(a)sensei.co.uk>