Re: catting random bytes causes character craziness

"Stephen J. Turnbull" <stephen(a)xemacs.org&gt; writes: OK. But it shouldn't be that hard to change this? Or am I missing something? The "locale support" might do several things: a) Check the appropriate variables and set the language environment accordingly. b) Set things up so that the LC_* settings really are respected in most reasonable circumstances. For example, in a UTF-8 environment, Mule would treat unknown input as UTF-8. This includes file input, shell buffers, etc. Needless to say, ISO 2022 autodetection should be turned off by default. c) Make especially sure that in single-byte language environments (e.g. the "C" locale and iso-8859-* locales, but not e.g. UTF-8) the conversions from external to internal format and vice versa are reversible. That is, if you run M-! cat binary-file, you should be able to save the resulting output buffer into another file without loss of data. The same should work in a shell buffer, modulo perhaps the newline detection. d) Get rid of ISO 2022... use UTF-8 as the internal representation... Oops. I understand that -- I merely wanted to correct the "this can't work for everyone" part and its Tel Aviv corollary. It can't work perfectly for everyone, but it could work much more reasonably by default for most people. I don't think what I proposed above really requires rewriting Mule, except for the part about getting rid of ISO 2022. But remember that since Jamie is probably running in a Latin 1 locale, and the `iso-8859-1' encoding is already free of the ISO 2022 lossage, he'd be ok.