[Q] Don't set the current langenv to ja just because someone used a japanese IM

[Stephen J. Turnbull]

Aidan Kehoe writes:

 > The buffer is mostly irrelevant to the problem I see. I want to
 > type some Kana on my Western European keyboard; I press C-u C-\
 > japanese-skk RET , then input konichiwa . The Kana come up as
 > question marks (this is on the TTY). When I examine the current
 > console-tty-coding-system, it’s EUC-JP, not UTF-8 as my startup
 > files configure it to be.

What is your LANG?  I bet it is also *.UTF-8, nyet?  In other words,
the Japanese (and others, I bet) language environment is basically
hosed because it forces an encoding.

 > I did not ask for the current console-tty-coding-system to be
 > changed;

set-language-environment shouldn't do that, anyway.  TTY (process,
file name) coding systems are properties of the system, not of Emacs.

 > nor did I ask for the unicode precedence list to be changed,

set-language-environment should do that, which is very bad in your
application, admittedly.

 > or anything of the sort. All I wanted was the input method,

I don't really care what *you* want; not only can you take care of
yourself, but you are a rare bird engaging in unusual multilingual
behavior.  You should not be changing global behavior for your
personal convenience.  You should be thinking about how to disable the
global behavior temporarily, or (in this case) turning the global
behavior into a more localized one.

 > and that temporarily, but because activating the input method
 > loaded skk-leim.el the whole shebang went astray.

The "whole shebang" is a stupid design in the context of multilingual
users like you, and we should make it go away.

 > I’ve also been told in the past that it’s a general principle of XEmacs
 > packages that loading a file should be idempotent, and that there should
 > ideally be further steps necessary to activate it the feature that it makes
 > available.

Yup.  But you didn't follow that principle.  You simply removed the
behavior that was inconvenient for you, rather than moving it where it
belongs according to that principle.  That may be the right thing to
do, but you haven't convinced me yet.  I know from experience that
it's very easy to start inputting Japanese (eg, with Canna) under a
non-Japanese environment and get a file full of junk readable only in
Emacs (and not always).

I think a reasonable solution here would be to delete the
set-language-environment call, as you did, and add a language
environment check to the skk activation function, which warns if 
the language environment is not Japanese.  Alternatively there could
be a variable controlling response to a non-Japanese environment,
taking values like 'set, 'warn, 'ignore.

What do you think?