>>>> "Glynn" == Glynn Clements
<glynn(a)sensei.co.uk> writes:
Glynn> SL Baur wrote:
> > I installed eterm-1.04, and noticed that the CR characters
> are being > eaten without eterm actually doing a carriage
> return, resulting in the > `staircase effect'.
>
> Verified. Note that the newest version of eterm has ANSI color
> support (color ls works, although the effect is lost in the
> ugliness of the staircase).
I get the same result in eterm 1.01.
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.
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.
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....)