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

[Stephen J. Turnbull]

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

         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.

    rms> Are you saying that everything ought to work now, in the
    rms> simplest case where someone sets these environment variables
    rms> and then starts Emacs and uses that X input method?  (Does
    rms> Emacs in fact work in this case?)

Emacs 20.7 does, at least for Japanese on my system.  I haven't had
time to try 21.1 yet.  (It should.  I insert the caveats because XIM
is one thing that the X people seem to mess with in every release, and
it has historically been buggy, so workarounds may have to change with
Emacs changes.)

    rms> The idea of being able to change X input methods within Emacs
    rms> sounds useful, if someone wants to do it.  What would Emacs
    rms> have to do to switch this in mid-session?

Close any open XIC (XIM input context---maybe unnecessary but seems
safest), setlocale LC_CTYPE to the appropriate locale,
XSetLocaleModifiers for the new input manager, XOpenIM the new input
manager, XCreateIC the new input context.  Optionally setlocale back
to the user's preferred locale.

Note that the original XIM handle remains valid and can be used to
open new XICs for the old XIM, and thus you can switch back and
forth without further messing with setlocale.  (All in theory, I
haven't played with this in a long time, and I don't remember exactly
what experiments I did.)

    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).

    rms> It is not hard to specify a different language environment in
    rms> Emacs.

No, but what happens if you want to mix and match to create a custom
language environment (which is what the user in question is more or
less doing)?

I don't use language environments because the XEmacs implementation
very much gets in the way; I prefer to manipulate things directly, as
I have to do that anyway for testing.  So I'm not really familiar with
"advanced use."

    rms> One other thing--should the choice of input method be
    rms> buffer-local?

I would think so.  It would be really annoying to drop out of your
Japanese text to reply to mail in Hangul, then type ahead in the
Japanese buffer and end up with it full of Hangul junk (and I mean
real junk because you'd be typing Japanese at a Korean method).

However, this could be tedious to implement.  XICs are bound to a
single X window, the value of the XNClientWindow argument to
XCreateIC.  So you'd need to check that every time the buffer/window
binding changed, keep a list of XICs used in the window, and you'd
need to flush and clone XICs every time the buffer appeared in a new
window.  Also, XIM will happily let you leave half-composed text in
the preedit area; it would be disconcerting to use a buffer switching
command to change to a buffer with half-composed text available in a
different Emacs frame.

    rms> If so, is there anything better we can do than
    rms> tell X to change input methods each time the user switches
    rms> buffers?

Actually you would switch XICs.  This should not be a very heavyweight
operation.

    rms> I think once that is done it will be easy to integrate the
    rms> two interfaces at the Lisp level even if they are controlled
    rms> by different C primitives.

You're right.  This is known easy; we've been doing it for years with
Canna, Wnn, Wnn6, and SJ3.  LEIM is quite happy to handle that.  The
hard part is going to be getting the XIC to appear to associate with
buffers, rather than X windows.



-- 
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.