Re: per-buffer language environments

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Kenichi Handa <address@hidden>,
>     address@hidden
> Date: Tue, 14 Dec 2010 20:38:43 +0900
> 
> Eli Zaretskii writes:
> 
>  > > * Which coding systems have higher priority when inserting a
>  > >   file in the current buffer.
>  > 
>  > I could understand how the font selection and the default input method
>  > are related to the language, but what do encodings have to do with
>  > that?  The preferred encoding is generally an attribute of a locale,
>  > not of a language.
> 
> Note the word "insert", which implies "read".  It is certainly true
> that a locale may specify an encoding.  However, if the person is
> Japanese, they may specify ja_JP.UTF-8 for their locale and strongly
> prefer that files be written with that encoding, yet still need to
> read files in other encodings.  The locale encoding of UTF-8 is no
> help in distinguishing an EUC-JP file from an ISO-8859-1 file, let
> alone an EUC-CN file.  OTOH, somebody with a Hebrew language
> environment and a locale specifying UTF-8 as the encoding almost
> certainly prefers that a file containing 8-bit-set octets inconsistent
> with UTF-8 be recognized as ISO-8859-8 rather than EUC-JP, no?

Those are all valid concerns, but they are just the tip of an iceberg.
There's an almost infinite number of combinations of a language and
the preferred encoding, and it's impossible to fold them all, or even
their significant fraction, in a reasonably usable user-level
interface.  We shouldn't even try, IMO; we already have
prefer-coding-system, the coding: cookies, the .dir_locals meta-data,
etc. to cover the situations where the user knows what encoding should
be preferred/used, even though her language and locale say otherwise.

set-language-environment accepts a single string, which should be a
language name, as its argument.  (There are some "languages" that we
recognize, such as "Chinese-GB18030", which sneak in the encoding as
well, but that's an anomaly, I think, which goes back to when Emacs
didn't have locale environments to express that.  Now that we do, we
could get rid of that, at least in principle.)  Therefore, a language
environment should set the defaults suitable for the language, and
that doesn't include the encoding, or at least does not have to fit
each minor cultural variant of the language.

>  > The fact that we mix them is because Emacs had
>  > language environments before it had locale environments.
> 
> What's a "locale environment"?

See set-locale-environment.

> AFAIK Emacsen use the locale as a heuristic for determining the
> language environment

There's no heuristic involved, AFAIR.  Emacs has a database of
languages _and_encodings_ suitable for the known locale names.
set-locale-environment uses that database to get the language and the
preferred encoding(s), then calls set-language-environment with the
language, and sets the priorities of the encodings according to the
encoding preferences.