Re: catting random bytes causes character craziness

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.... 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. 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? Even though you know that most of the rest of us can't pronounce either name correctly, you don't want them displaying as octal escapes (or worse, characters from the wrong set). This is _not_ just a problem of files that are gobbledygook to most current. It is a problem of files that are quite readable, too. Hrvoje> Doesn't Ben have a workspace with working Unicode? Or is Hrvoje> it too alpha? Much too alpha. Minimum six months to gamma, and I doubt it will be working any better than current Mule from your point of view until we beat on it for a year. Ben is smart, I could be wrong. But (until the whole world speaks Unicode and nothing but Unicode) this is not a problem that yields to Ben-smart. Ben's workspace is known to have many "_nobody_ wants it this way" default configuration bugs. Ie, it's a problem that has be dealt with via Handa-persistent. (Granted I wish Ben or Erik had designed Mule! even now he's constrained. :( ) 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. Not even in Ben's workspace. Sorry. You can have binary. 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. But we are definitely talking very alpha here. Hrvoje> True. However, we needn't stick to the POSIX locale like Hrvoje> crazy, either. In Japanese locale, we could enable Hrvoje> auto-detection. I don't work in a Japanese locale; for my purposes POSIX is too broken to work in any locale but "C". Mule works fine in that context, as designed. 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, and want it to go to some effort to make texts handed to it readable, to the author if not to the reader. They don't expect their text editor to be reliable in the face of binary data without special effort. as possible, we should be working to make it more reliable. We still need a be-stupid switch, as Jamie puts it. But it should be t, not nil, by default. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.