>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
> This is true of Mule-UCS, it's not true of Unicode support,
at
> least on Windows, in 21.5.
Hrvoje> Why "at least on Windows"? It would be a shame if the
Hrvoje> 21.5 Unicode support were somehow tied to Windows. If
Hrvoje> anything, it would leave out all the Unix users -- a vast
Hrvoje> majority.
It's not "tied" to Windows, it's just that Unicode is the native
coding system of Windows and therefore Ben made sure implementaiton is
complete there. As far as *I* know Unicode support on Unix is
complete, but my experience is limited to ISO 8859/1 and Japenese,
which are special cases (remember, ISO 8859/1 is another name for
binary, it's implemented differently from the other ISO 8859 systems).
> >> > Charming. Why do we ever fall back to
"iso-2022-jp" for
> >> > things we send over the wire? Signalling an error would
> be >> > kinder to the user and her correspondents.
>
> Since when do we "fall back" to iso-2022-jp?
Hrvoje> I don't know, but that's what the code comment seems to
Hrvoje> indicate.
What code comment? Maybe that's true of VM, but that's not "we",
that's "Kyle".
> It's a misreading of the correct statement that ISO 8859
> defines versions of ISO 2022 to permit use of facilities like
> designation of additional charsets. ISO 8859 doesn't permit
> that.
Hrvoje> [...]
> What we do have is latin-unity, but you don't like that
either.
Hrvoje> latin-unity pretty much broke my XEmacs when I tried it.
Hrvoje> For example, byte-compiling a file prompted me with
Hrvoje> questions I didn't know how to respond to. (There were
Hrvoje> other examples of similar breakage.) Perhaps those bugs
Hrvoje> have been fixed in the meantime, I don't know.
What questions? I don't see any questions when I byte-compile a file
with latin-unity active, although I did see it in prototype versions.
Perhaps you had an old version of latin-unity?
As for "bugs", those are features. Latin-unity was not designed to to
take over the computer like Mule only better, it was designed to give
the user control over what the computer does to his data. If the user
doesn't know, he at least can ask "WTF?" before Mule destroys data.
latin-unity provides an interim framework for configuring the safety
net; it's not a real long-run solution.
Hrvoje> BTW in the quoted text you seem to be implying that
Hrvoje> latin-unity somehow implements a more correct ISO 8859,
Hrvoje> e.g. allowing me to read files as Latin 2 without
Hrvoje> interpreting ISO 2022 sequences. Did I misread it? I
Hrvoje> wasn't aware that latin-unity did anything of the sort.
I don't know of any way to read files containing ISO 2022 escape
sequences as ISO 8859/2 without interpreting the escape sequences in
current Mule. This will happen with the binary coding system, which
will display as ISO 8859/1, but that's the best you can do as far as I
know. What latin-unity does is to prevent coding systems from
dropping out-of-range characters on the floor and replacing them with
"~" on file and process writes.
Hrvoje> My point is that we should strive to remove such code, not
Hrvoje> add more of it. YMMV.
> I agree, but not at the expense of corrupting user data.
Hrvoje> I don't know what corruption you're referring to, but I'll
Hrvoje> take your word for it.
Replacing buffer data with "~" when writing a file.
--
School of Systems and Information Engineering
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.