"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
Hrvoje> Except, last time I checked, XEmacs/Mule completely
Hrvoje> ignores the user's hints as to how he'd prefer to handle
Hrvoje> the "binary octets".
It still does. That's one of several reasons why --with-mule _still
defaults to_ *no*.
OK. But it shouldn't be that hard to change this? Or am I missing
The "locale support" might do several things:
a) Check the appropriate variables and set the language environment
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...
Jamie chose to go with a vendor which doesn't offer a non-mule
(maybe you have some pull with them ;-). He chooses not to build
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.
Jamie, I sympathize with you, but I can't help you very much
those circumstances. I have neither the time nor the knowledge to
rewrite Mule for 21.4.11
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