Re: coding-system lossage with eterm
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).
Yep; that was the main reason for upgrading. BTW, I tried reverting to
the previous version (1.02), but it has the same problem, so it's due
something that's changed in XEmacs rather than than in eterm.
> Using (setq process-coding-system-alist '((".*" .
binary))) fixed the
> problem,
Does it? What happens if you cat a Japanese text file? I see something
highly ugly and definitely not Japanese.
I see pretty much the same as if I cat a Japanese text file in an
xterm.
> but it smells as if eterm is assuming that the coding system is
> appropriate rather than making it so.
Yup.
> Is this MULE-related?
I'm pretty sure. As far as I know, eterm has never been MULE-ized.
Could someone knowledgeable please do up an appropriate patch?
Actually, I suspect that it's more likely coding-system related. I've
built with MULE for about as long as I've been running beta versions
(although my knowledge of languages other than English is roughly
nil), and eterm used to work OK.
Any suggestions as to what coding system it should set? Or should it
be a defcustom? In which case what would the default be?
--
Glynn Clements <glynn(a)sensei.co.uk>