Re: address@hidden: Re: X Input Methods support is not very convenient]

[Stephen J. Turnbull]

>>>>> "rms" == Richard Stallman <address@hidden> writes:

    To address the current issue, you would just temporarily set LC_CTYPE
    to the locale needed for the user's choice of input method, and
    XMODIFIERS to the input method's identification string.

    rms> I am not sure what it means to speak of the "locale needed
    rms> for the user's choice of input method".  Are you talking
    rms> about Emacs input methods or X input methods?  If the former,
    rms> they do not have any locales associated with them.

Correct.  I'm talking about the X input methods.

I would like to go farther and allow XIM (and native IIIMF, if they
appear, iiimecf.el (?) seems to be an all-Lisp implementation?) 
methods to be registered with LEIM.  But I believe this to be a more
complex project in itself, because of the interaction with the
recommended X11 style of passing everything to XFilterEvent.  That
immediately suggests further work, such as allowing Emacs to peek at
the event before passing it to XFilterEvent in order to avoid the IM
eating up ASCII characters from multi-keystroke sequences.  (This may
not be a problem for GNU Emacs, but it can be very annoying for
toolkit-based Emacsen which don't explicitly call XFilterEvent.)  It
should also be possible to allow multiple XIM-based input methods to
be switched on the fly.  I've also experienced hangs when I've
misconfigured the backend; neither Xlib nor kinput2 seems to time out
on my system if the jserver can't be found.

    rms> If the latter, this might make sense but I don't have any
    rms> information about them.  How does one find out the locale
    rms> needed for an X input method?

This is implementation-dependent with each method, and the user should
know.  In the normal circumstance, users will set LANG and XMODIFIERS
in their shell environments, Emacs inherits, no problem.  Here we have
a sophisticated user playing games with the locale system.  It will be
easy for him to figure it out, he's got this far by himself.

    rms> Currently Emacs does not set XMODIFIERS.  Does that mean it
    rms> is inherited from the user's environment?  If so, isn't it
    rms> the user's responsibility to make sure that LC_CTYPE and
    rms> XMODIFIERS fit together?

Correct.  In fact, they are more or less independent of each other.
By that I mean that if you set LC_CTYPE=ja_JP, then you can set
XMODIFIERS="@im=kinput2" or XMODIFIERS="@im=xwnmo" to use one of two
alternative XIM input managers.  On the other hand, I believe (never
tried it) that with XMODIFIERS="@im=xwnmo" you can set LC_CTYPE=ja_JP
or LC_CTYPE=ko_KR because Wnn can handle both Japanese and Korean.

The current problem arises when a user is multilingual but wants to
use XIM.  Setting LANG outside of Emacs to the locale in which they
plan to use XIM can cause problems in buffers used for other languages
(the user has to undo the automatic setting of the language
environment according to the locale in Emacs's environment).  Also,
there can be annoyances when the environment is passed to
subprocesses, such as those used by dired and ange-ftp.  So it seems
like the easiest way to get it all right is to avoid disturbing
current Mule language environment mechanisms, and allow the user to
specify her own LC_CTYPE and XMODIFIERS for XIM within XEmacs (maybe
in .emacs or with command-line siwtches), and leave that up to her.

Of course if the user doesn't do so, they would default, as now, to
inheritance from the Emacs process's environment.

-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
              Don't ask how you can "do" free software business;
              ask what your business can "do for" free software.