.FN!set-language-environment.FN" should set .FN!language-unicode-precedence-list.FN"

[Aidan Kehoe]

 Ar an chéad lá de mí Lúnasa, scríobh Mike FABIAN: 

 > Aidan Kehoe <kehoea at parhasard.net> さんは書きました:
 >
 > > The reason there isn’t a German (UTF-8) locale available when you start
 > > in a Japanese UTF-8 locale, is that there is such a wide and legitimate
 > > variation in the coding systems used with a given language under
 > > Unix--English in ISO 8859-1 vs. English in ISO 8859-15 vs. English in
 > > UTF-8 vs. English in CP1252, to pick a simple example--that it makes
 > > more sense to pick one as canonical
 > 
 > But then I would like to have the UTF-8 variants as the canonical ones
 > because UTF-8 is the default on the systems I use.

Should they be the ones picked up if LANG is just "de" or "ja" ? That’s what
I meant by “canonical,” the one chosen if language information but not
character set information is available from the environment.

 > Having UTF-8 only for the language I use during startup and not for the
 > others makes changing the language-environment totally useless because
 > it messes up the encoding for external processes (and even for the
 > XEmacs menu bar when opening new frames with “C-x 5 2”!).
 > 
 > > and create a variant if a corresponding LANG or LC_CTYPE is seen. 
 > > If you want a German UTF-8 locale despite not having LANG as de_??.UTF-8 in
 > > your environment at startup, call:
 > >
 > >   (set-language-environment
 > >     (create-variant-language-environment "German" 'utf-8))
 > 
 > Nice, I can use this in site-start.el for the time being.

OK. But if your users start up in the appropriate locale, as most of them
will, that shouldn’t be necessary.

 > > set-language-environment is supposed to be a cross-platform API, so my
 > > feeling is that we shouldn’t do this automatic generation of new language
 > > environments within it for what is essentially a Unix quirk;
 > 
 > But if it is a Unix quirk, then why not do it on Unix?

For the sake of a consistent cross-platform API :-) . Unexpected behaviour 
makes things harder to maintain, normally. 

 > > the system locales under Windows are basically fixed in the coding
 > > systems they use.  But if you think otherwise, say so, and I’ll think
 > > about it some more.
 > 
 > I wouldn't mind to have several possible values for language-environments
 > for each language. Do you think that will confuse people?

I have 156 POSIX locales on this FreeBSD machine; but only 41 separate
languages are used in those locales. Maintaining around 40 language
environments within XEmacs is more practical than maintaining around 200
(since I’m sure FreeBSD omits plenty).

It’s not really a question of user confusion if the user gets the correct
language environment by default, which most of them should if their POSIX
locale is correctly set.

Would adding information to the set-language-environment docstring about
create-variant-language-environment make things easier? 

 > The confusion is already there because all these locales exist
 > unter Unix, having them available in the language-environments doesn’t
 > make it any worse.

It makes it worse on Windows, though. And yes, Windows isn’t your problem.

 > If one absolutely wants to reduce confusion by reducing the number of
 > choices, then I think the non-UTF-8 choices could be removed if one
 > starts in an UTF-8 locale because in that case the non-UTF-8 ones are
 > almost useless anyway.

-- 
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)