Re: Horrible term-mode problems on upgrade to 21.4

The following message is a courtesy copy of an article that has been posted to comp.emacs.xemacs as well. [Cc:ed to xemacs-beta. I am not subscribed to this list; please Cc me on any replies. If this is an obvious MULE-like thing that people have been coping with for ages, please forgive me; I've never built anything MULEish into my Emacsen before.] On 11 May 2001, Nix stipulated: [snip classic typewriter `staggering'] Diagnosed. I built with --with-file-coding on a Unix platform, so XEmacs is looking at the data coming to the file and transparently translating CR/LF to LF. All very well, except that in term mode, CR/LF's come in and are interpreted by `term-emulate-terminal' in a DOSsish fashion, with CR and LF serving their ancient teletype purposes; as this is how TTYs work, this is entirely correct. What is *not* correct is XEmacs picking up on the CR/LFs and translating them to LFs! I'd fix term-mode, if it wasn't that setting the `buffer-file-coding-system' to `no-conversion' still gives the stair-stepping effect, and that even before that it's `raw-text', so XEmacs shouldn't be touching the bytestream from the process at all. (It's questionable whether `--with-file-coding' should touch process streams in any case; it'll be built in for people trying to transfer files between DOSsish and Unixish environments, not processes!) So this looks like an XEmacs bug; however, I don't have a clue how to go about fixing it; as I said above, I'm a neophyte at *using* MULE, let alone debugging it. (Reproduction of the bug is easy, as near as I can tell; build --with-file-coding on a Unix box and run term-mode or anything based on it, like tshell. Bingo.) -- `LARTing lusers is supposed to be satisfying. This is just tedious. The silly shite I'm doing now is like trying to toothpick to death a Black Knight made of jelly.' --- RDD