>>>> "Hrvoje" == Hrvoje Niksic
<hniksic(a)xemacs.org> writes:
Hrvoje> It is my understanding that "un-define" and "unicode"
are
Hrvoje> not merely deprecated, but that they have always been
Hrvoje> unfinished, buggy, and ultimately unsupported. I could be
Hrvoje> mistaken.
This is true of Mule-UCS, it's not true of Unicode support, at least
on Windows, in 21.5.
> > 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? If you're talking about
the buggy implementation of ISO 8859, that's exactly what it is; it's
not falling back to Japanese localization. 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.
The reason why changing those implementations at this time is that the
alternative is complete corruption. I've tried implementing error
signalling in the coding systems and it's not easy, because you're an
apparently nondeterministic level of recursion inside of the lstream
code.
What we do have is latin-unity, but you don't like that either.
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.
--
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.