XEmacs doesn't support windows-1252

[Aidan Kehoe]

 Ar an t-aonú lá is triochad de mí Iúil, scríobh Stephen J. Turnbull: 

 > Aidan Kehoe writes:
 > 
 >  > Stephen’s comment in Unicode.c (below) is incorrect when it comes to
 >  > Cyrillic in that we’ve only ever supported cyrillic-iso8859-5 as an
 >  > internal character set for most of Cyrillic, mapping to it on decoding
 >  > and from it on encoding, so koi8-r and windows-1251 would never have
 >  > been in the list; it’s also incorrect in that Chinese-Big5 and
 >  > Chinese-CNS have been separate language environments in Mule whenever
 >  > Chinese-CNS was supported in the context of language environments,
 >  > which it mostly hasn’t been. So to me it does make sense to add
 >  > support for calling this function to the language environment code.
 > 
 > I think you're missing the point.

Does it make sense to add support for calling this function to the language
environment code?

 > People in Taiwan (at least Buddhist scholars :-) do use both character
 > sets, and if there happens to be separate -Big5 and -CNS environments
 > that differ ONLY in charset precedence (as seems likely to occur for
 > Taiwan)

If the user is under Unix the language environment is normally determined
from the environment (and rightfully so), where the most-used coding system
is as granular as it gets. For zh_TW.Big5, the effective Unicode precedence
list should place Big5 before the CNS character sets; for zh_TW.EUC-TW, it
should place the CNS character sets before Big5, since they are what EUC-TW
encodes; and for zh_TW.UTF-8 it should place Big5 before CNS, since Big5 is
far more popular than CNS. There are no other POSIX locales specific to
Taiwan.

That is, under Unix there is no way to automatically work out that two
Chinese-as-used-on-Taiwan language environments should only differ in the
preferred Unicode precedence list of the user, so if we are to offer such
differing (XEmacs) language environments, the user needs to call Lisp to do
this. And (set-language-environment "Chinese-UTF-8-prefer-CNS”) (or some
other less unwieldy name) is not hugely less awkward than
set-language-unicode-precedence-list.

If the user is under Win32, it seems even less likely that it can be
automatically determined that a given user prefers CNS over Big5, since the
only Traditional Chinese language environments available are based on Big5.

 > switching between them is equivalent to users calling s-l-u-p-l directly.

Which is fine, since it cannot be done automatically.

 > So I don't really see the point of having separate s-u-p-l and
 > s-l-u-p-l functions.  Most users don't care; it will be set once,
 > correctly, by their primary language environment, and they'll never
 > have a desire to change it.  Those who *do* want to change it will, as
 > you do here, use s-l-u-p-l, not s-u-p-l, because it has higher
 > precedence.

Maybe, but that’s not what you wrote. Your comment was above
set-language-unicode-precedence-list, and said that *that* interface was
wrong, whereas as you describe it there, *that* interface is the right one,
and *set-unicode-precedence-list* is mostly useless, which is a position I
agree with wholeheartedly.

-- 
On the quay of the little Black Sea port, where the rescued pair came once
more into contact with civilization, Dobrinton was bitten by a dog which was
assumed to be mad, though it may only have been indiscriminating. (Saki)