Re: XIM, kinput2 & Tk

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

Caveat: everything below is consistent with my experience, the
O'Reilly manuals (X11R5), the X Consortium Xlib and Xt manuals
(X11R6.3), and the XIM standard (X11R6.3) IIRC ;-).  But I haven't
read either Xlib or X server code, and it's been quite a while since
I've looked at kinput2 code.

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

    Jim> From this I conclude that the initiation sequence is detected
    Jim> by kterm, and it whistles up kinput2.

Yes.  I believe this is the "illicit intimate knowledge" that Chris
mentioned a while ago.  XEmacs doesn't have any such resource AFAIK,
but XIM works fine.  If you start up kinput2 in +xim mode (ie, without
XIM, thank you very much X11), XEmacs doesn't work mith kinput2 at
all.  kterm will, though, using the kinput protocol.

    Jim> When kinput2 receives a request, it pops up a window and
    Jim> starts conversion process." No mention whatsoever that traps
    Jim> the sequence itself.

Right.  _Xlib_ does the trapping, not kinput2.  But it does it for
every single keystroke.

    Jim> However, the man page for XOpenIM says:

    Jim> 	"The XOpenIM function opens an input method, matching
    Jim> the current locale and modifiers specification."

    Jim> This seems to contradict what Chris said, unless "locale" is
    Jim> loose and includes the values in LANG.

Locale is not very well-defined in the POSIX standard (or anywhere
else), and app writers insist on adding interpretations which fall
outside of even the loose POSIX definition.

    Jim> Another question. Having multiple languages in LANG is
    Jim> presumably OK?  I currently have it set to "en_US ja_JP", and
    Jim> RH seems to behave with it.

No, I have no idea what that means.  There is a GNU extension
environment variable, LANGUAGES, which gives a series of fallbacks for
gettext() and friends.  But POSIX locale is unique to a given process
at any instant of time and there are no fallbacks once it is set
(implicitly to C or via setlocale()).

    >>> From: Christopher SEKIYA <wileyc@example.com>

    >>> Wrong sequence.  It goes like this (for XIM, which I'm really
    >>> growing to hate):
    >>> 
    >>> * application creates a callback via XOpenIM()
    >>> * Xserver receives a key sequence indicating a request for
    >>> input method intervention

Well, Chris might know more about implementation details, I haven't
read the relevant server or Xlib code.  But as I understand the XIM
protocol standard, the callback created via XOpenIM() (actually,
XOpenIC(), see below) "pipes" _all_ keystrokes to the input manager
(eg, kinput2).  Thus, neither the app nor the X server needs to know
what the "initiate" sequence is.  I know for sure that it is possible
to get kinput2 to wake up on sequences that kterm doesn't know about
(or maybe it's the other way around, kterm may get no joy using the
sequence it knows about although kinput2 is alive and kicking---but
waiting for a different one---don't bother, Chris, we already know
what you think of these protocols :).

In the kinput protocol (non-XIM), no keystrokes are passed to kinput2
until the "initiate" sequence is entered.  That's why kterm needs to
know what the initiate sequence is.  I believe it ignores it for XIM,
but I haven't looked inside kterm for a while.

    Jim> Where are these keystrokes defined?

Solely by the XIM input manager, eg, kinput2.  An app like XEmacs
might want to know about them, so that you can avoid binding other
functions to those keystrokes or issue a warning (I've always detested
the C-o binding that Canna and Wnn use, I use open-line quite a bit;
there is not such a problem with kinput2, but there _could_ be).

So for XIM you should be able to customize all apps that use kinput2
with

	  kinput2 -xrm "*conversionStartKeys: Alt<key>Kanji"

(assuming kinput2 understands the standard Xt options).  I don't think
there is any way to have different settings for different clients.
(Well, there is, but it's too disgusting to mention in front of Chris.)

    >>> (yes, that's a bit of a simplification -- Steve will set me
    >>> straight if it's too simple)

No, it's too complex AFAIK.  Omit the part about the server waiting
for an "initiate" sequence.  I think you're thinking about the
XOpenIC() call, which I believe has to be passed through the X server
(the logical candidate for coordinating console, app, and XIM input
manager since it needs to talk to all three anyway).  But that normally
is done early by the app (XEmacs for example does it every time an
emacs frame is created), not on demand.


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