XIM, kinput2 & Tk

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Jim" == Jim Breen <jwb@example.com> writes:

    Jim>  Needless to say, the documentation for I18N is totally
    Jim> silent on this.

Er, well, the O'Reilly X manuals cover it pretty well.  Except that
AFAICT they haven't really tried the more esoteric stuff, so whether
it works as documented in the fine points is questionable.

Here's the theory:

(1) An XIM-using app enables XIM by setting up an event filter that
    redirects X events of interest (including all keypress and
    keyrelease, grabs, focus, etc, and usually certain window events)
    to the XIM functions.

(2) It explicitly opens an X Input Method:

    (a) It sets the program's locale using the standard library
        function setlocale(), either from the environment (default) or
        explicitly.  Eg, "ja_JP.eucJP".  I think it specifically looks
        at the LANG and LC_ALL variables, but not at any of the
        subcategories.

    (b) It gets the (possibly program-augmented) contents of the
        XMODIFIERS environment variable.  This is a string of the form

        "@example.com=value;@example.com=value..."

        AFAIK the only implemented tag is @example.com  Then it extracts the
        order list of input methods such as "@example.com=isoaccent;@example.com=kinput2".

    (c) Then it does XOpenIM(...).  XOpenIM walks the list, attempting
        to contact each method in turn, and on success asking "do you
        do $LANG?"  isoaccent says "ja? bu-wha-ha-ha!".  XOpenIM
        translates that to "iie"[1], and goes on to kinput2.  Kinput2
        says "hai!", they shake hands, and XOpenIM returns a struct
        _xim or something like that that Xlib will use to control
        console input thereafter.

(3) Then it does further processing.

Note that VALUE is IM-specified; I don't know how it is implemented,
but kinput2 could register itself as "Alfred E. Neumann" if it wanted
to, and the XIM protocol would look up "Alfred E. Neumann" and somehow
know to contact kinput2.  Fortunately most input methods use their
names (in particular, XMODIFIERS="@example.com=kinput2" finds kinput2), but
they don't have to.  (The reason for this is so that a single server
can register itself multiple times; Xlib itself implements several
methods internally.)  IIRC case is significant.

Also note that if XMODIFIERS="@example.com=atok;@example.com=kinput2" you will get ATOK,
not kinput2.

Finally, there is no standard for processing $LANG, either.  In the
previous example, it's actually possible that ATOK insists on
"ja_JP.utf8" while kinput2 accepts "ja*", in which case kinput2 would
win if $LANG==ja_JP.eucJP.  Or ATOK could depend on the rarely used
modifier field in the locale spec, and look for "ja*@example.com", thus
losing on "ja_JP.eucJP".

In your case, you need (a) XMODIFIERS="@example.com=kinput2" and (b)
LANG="ja_JP.eucJP" (probably, works for me but YYMV) in your
environment or you will lose.  Of course, you may lose anyway; this is
XIM.

This is all an excellent idea, really it is.  Trust me.  Eh, Chris?
Pay no attention to the note at the bottom of the screen!  :-)


Footnotes: 
[1]  XIM is of course a Japanese invention.  Hideki used to be insane,
but then it got better and he wrote a much better spec for Java, IIIMF
or IIIMP or something like that (I forget which is implementation and
which is spec).

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."