"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
>>>>> "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.
Why "at least on Windows"? It would be a shame if the 21.5 Unicode
support were somehow tied to Windows. If anything, it would leave out
all the Unix users -- a vast majority.
>> > 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?
I don't know, but that's what the code comment seems to indicate.
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.
[...]
What we do have is latin-unity, but you don't like that either.
latin-unity pretty much broke my XEmacs when I tried it. For example,
byte-compiling a file prompted me with questions I didn't know how to
respond to. (There were other examples of similar breakage.) Perhaps
those bugs have been fixed in the meantime, I don't know.
BTW in the quoted text you seem to be implying that latin-unity
somehow implements a more correct ISO 8859, e.g. allowing me to read
files as Latin 2 without interpreting ISO 2022 sequences. Did I
misread it? I wasn't aware that latin-unity did anything of the sort.
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.
I don't know what corruption you're referring to, but I'll take your
word for it.