>>>> "Hrvoje" == Hrvoje Niksic
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
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. :( )
> 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
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
Hrvoje> True. However, we needn't stick to the POSIX locale like
Hrvoje> crazy, either. In Japanese locale, we could enable
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
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.
From that point of view, rather than disabling autodetection as much
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.