Reuben Thomas wrote:
Glynn Clements was inspired to write:
>
> Yes; however, I suspect that the problem lies elsewhere. Try this:
>
> (push '("/.*" . binary) process-coding-system-alist)
That did it. Brilliant!
> If that works, the problem is that term-mode was having "DOS to Unix"
> EOL conversion automatically performed on the output from the process
> (which is usually what's desired, but not for a terminal emulator).
So how come XEmacs seems to come set up like this by default?
Probably because term.el hasn't been updated to deal with the
introduction of coding systems (previously only MULE-enabled XEmacsen
had them).
Presumably because the above setting is what you want in, for
example,
M-x shell? Presumably what's needed is to set the above locally in the
term hook or something?
Well, I just use the above line to force the coding system to binary
in all cases. I'll change it if I ever find anything which breaks.
In any case, some fix ought to be added to
term.el (or wherever is appropriate) so that it works out of the box,
surely?
Yep. Calling set-process-output-coding-system from somewhere within
term-exec should do it.
I for one would not have guessed that fix in a million years;
for one, because I thought that the reason my line endings were fixed
automatically in shell mode was by lines like
(add-hook 'comint-output-filter-functions 'comint-strip-ctrl-m)
(add-hook 'shell-output-filter-functions 'shell-strip-ctrl-m)
in my .xemacs/init.el. However, now it seems as though these are
redundant...
The above are (mostly) redundant if the TTY is using the "stty -onlcr"
setting (although occasionally a program will change the TTY settings,
or output CRs of its own accord).
--
Glynn Clements <glynn.clements(a)virgin.net>