Re: catting random bytes causes character craziness
"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
Hrvoje> Or, emacs-lisp mode could simply recognize the Mule elisp
Hrvoje> files and do the right thing.
Er, it does that by recognizing ISO 2022 escape sequences, etc....
No, the reader does that. I was talking about adding magic to
emacs-lisp mode. The thing is, I'd like C-x C-f to *not* recognize
ISO 2022.
Hrvoje> Catting them in a shell buffer wouldn't display
Japanese
Hrvoje> contents, sure, but that's a feature, not a bug.
Huh? If you're catting them on purpose, that's a bug. Get real.
But, you see, I *really* don't want auto-detection of Japanese, and
neither does anyone I know. *Auto*-detection is the keyword here. If
the context calls for charset detection (as in a MIME message), or if
I instruct the computer to watch out for Japanese, then that's fine.
If, on the other hand, I cat random binary in a shell buffer, I want
to get that binary content in my shell buffer. This bug started by
Jamie's Mule thinking that his binary content was Hebrew or whatever.
For example, consider about.el. You want both Skyttä and
Nikšić to
display correctly in both Latin-1 and Latin-2 locales, don't you?
Yup. And about.el will store those names in a re-readable way and
decode them explicitly.
>> But that means that ISO-8859-X is also shut off, because
the
>> only no-conversion coding system is iso-8859-1-unix and its
>> aliases.
Hrvoje> In an iso-8859-2 locale, input bytes between 160 and 255
Hrvoje> should be considered Latin 2.
Mule doesn't work that way.
I know, but I'm saying it should. That's what people from those
locales expect, and the fact that it works totally different is the
reason they don't use Mule.
Sure, it could work that way, and I think Ben's 8-bit work will
support "proclaiming" the 8-bit stream to be ISO-8859-2 (or KOI8-U,
for that matter) by release time.
Being able to use the `iso-8859-2' coding system without inflicting
ISO 2022 escapes would be a good start, too. That way you could at
least code around Mule -- as it is, it's just too hard.
Again, if we are talking about "most users", you and Jamie
are in
the minority. Most people use Emacs as a human-readable-text editor
I don't agree with the "minority" assessment. In my experience,
people who use Emacs are very advanced and use it for programming and
all kinds of random editing. People who use shell mode are even more
"advanced".
They don't expect their text editor to be reliable in the face
of
binary data without special effort.
Maybe -- but they might expect their editor to at least respect the
locale. People running in a Latin 2 locale are simply not used to
their editors randomly garbling binary data.
True, you need to edit binary data very rarely, but when you do, you
*really* do. Emacs's ability to edit binary has saved my ass a number
of times, and I'm not the only one.