Re: address@hidden: `set-locale-environment' bug]

[Eli Zaretskii]

> Date: Wed, 12 Nov 2003 11:40:15 +0900 (JST)
> From: Kenichi Handa <address@hidden>
> 
> It seems that all settings about display table and terminal coding
> system is done by dos-codepage-setup via term-setup-hook.

Yup.

> So, mule-cmds.el should do nothing for them on DOS, right?

I'm not sure.  First, dos-cpNNN-setup still calls
set-language-environment (and the user could theoretically set some
language environment manually).  standard-display-european-internal
could also be called in some unexpected way, even on DOS.  So
mule-cmds.el shouldn't do anything that's wrong for the DOS port; this
the DOS-specific code in standard-display-european-internal and in
set-language-environment.  We could, of course, move the DOS-specific
parts to term/internal.el so that mule-cmds.el is cleaner.

> I think we must think over making the code in mule-cmds
> clearer now.  The current code is quite confusing and it
> seems that there are bugs.

I wouldn't be surprised, given the amount of changes that went under
the bridge since that code was written.

> So, for instance, if we start in some European locale in
> multibyte mode, standard-display-european-internal is
> called, but when we switch to Japanese lang. env., the
> standard-display-table is not reset.  On the other hand, if
> we start in Japanese locale in multibyte mode, even if we
> switch to some European locale,
> standard-display-european-internal is not called.

I see how this happens (set-display-table-and-terminal-coding-system
is called in the multibyte mode from set-locale-environment, not from
set-language-environment), but I'm not 100% sure this is a bug.  I
think we need to discuss the meaning of changing the language
environment without switching the locale.  When would a user want to
do that, and what should Emacs do to adapt itself to such a situation?