Re: Setting file-name/process coding system from LANG

[Miles Bader]

Kenichi Handa <address@hidden> writes:
>>>  Then a user can't recover that original setting when he once
>>>  switch to, e.g., Latin-1.  Just switching back to Japanese
>>>  can't setup coding systems for utf8.
>
>> Why can't we do what I suggested earlier, and set `file-name-coding-system'
>> (and presumably some analogue for process I/O and terminal-coding-system)
>> instead of `default-file-name-coding-system' from the "utf8" portion of LANG?
>
> If it always sets file-name-coding-system, there's no need
> of having default-file-name-coding-system.

Sure there is:  it gives set-language-environment something to set.

In other words, the setting established by set-language-environment is a
_default_, but the setting established by LANG (or by the user
explicitly, if uses `C-x C-m whatever') is `real'.

> And, that means that even if one changes to latin-1 lang. env.,
> file-name-coding-system is still utf-8.  Is it ok?

I'm not sure; it could be.  LANG primarily seems to describe the way
programs should interact with other programs and the user, but
`language-environment' seems a bit more vague.

A user might very well change the language-environment to get various
customizations for his own typical usage -- LEIM input system, tutorial
language, file-coding priorities -- but he's still using the same
system, his terminal hasn't changed, etc.

If we assume that LANG was set correctly for this system (it describes
the way typical tools work), then it seems reasonable for emacs to
continue interacting with the system in the same way even if the user
changes the language-environment.

However if the user uses `set-language-environment' because LANG wasn't
set, or because it was set incorrectly, he probably wants it to override
everything.

Which of these scenarios is more common?  I'm not sure, but it doesn't
seem unreasonable to assume that _if_ LANG contains an explicit coding
system, that it's "correct".

[BTW, another thing: if set-language-environment _does_ change the
process-related coding systems, it probably also ought to change the
value of LANG that subprocesses get, so at least it's _consistent_...]

>>>  Another problem is the case of LANG=zh_CN.utf8.  Currently
>>>  we don't have Chinese lang. env.  We only have Chinese-GB,
>>>  Chinese-EUC-TW, Chinese-BIG5, Chinese-CNS.  Which one to
>>>  use?
>
>> Presumably whichever one best matches the "country" portion of LANG.
>
> % locale -a|grep zh
> shows these:
>
> zh_CN
> zh_CN.gb18030
> zh_CN.gb2312
> zh_CN.gbk
> zh_CN.utf8
> zh_HK
> zh_HK.big5hkscs
> zh_HK.utf8
> zh_SG
> zh_SG.gb2312
> zh_SG.gbk
> zh_TW
> zh_TW.big5
> zh_TW.euctw
> zh_TW.utf8

Well you could just choose whichever is most popular in each country...

[perhaps have an alist do mapping from "chinese country" to "chinese
lang. env." -- by default it would be sorted by popularity, but a user
could change it if he didn't like that... or just set the language
environment explicitly.]

-Miles
-- 
Yo mama's so fat when she gets on an elevator it HAS to go down.