[tlug] inline conversion with various terminals

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

Scott Robbins writes:

 > Today, on the ArchLinux mailing list, someone mentioned that the XFCE
 > Terminal does conversion inline.  I've always considered inline to be
 > about a line below the line I'm working on.  For example, if (using
 > scim-anthy, which was the conversion method the poster uses) I hit
 > ctl+space a box opens up just below the line of text I'm typing.  (I
 > remember a few years ago, talking about, on some Debian multi-language
 > terminals, a box would open below the terminal's window.

Technically, inline is called "on the spot", a window that tracks
the insertion point closely is called "over the spot", and a separate
window is called "root".

The difference is how much effort the application must put into
cooperating with the input method.  For root, it just wakes up the
input method, and accepts a string when the preedit phase (henkan) is
done.  Since this is actually done internally to the Xmb* and Xwc*
input calls, no effort is required.  For over the spot, the
application queries the IM, and provides a window.  I forget whether
the app or the IM manages the window, but this is easy, since geometry
management is easy.  For in the spot, you basically have to implement
curses. ;-)  It's hard to do well even with a monospace font.

 > I'm wondering what's special about XFCE to make it do that.

It has special code at the C level, providing callbacks to the input
manager that allow the input manager to insert, delete, highlight,
move the cursor, etc.

 > something within the range of my moderate skills, that I could do to
 > make other terminals, specifically mlterm,

In XIM-based input managers, you either need to be able to implement a
primitive terminal emulator, or get lucky.  If you're lucky, there's a
resource that you can set to on-the-spot to get that behavior.  The
fact that it's not default suggests that the implementation probably
sucks, though. ;-)

The name of the resource or option probably matches the regexp
.*im.*mode. :-)

I don't know about IIIMF and library-based IMs like SCIM and uim.  The
state of the art has advanced since I last worried about it; it may be
more commonly implemented, perhaps within the IM library itself
(although that would be very hard, I think).  (I've always used
on-the-spot.  XEmacs does its own display management simply by doing
normal editing operations.  It calls out to the library to get
candidates which it simply inserts in the buffer in the usual way --
it has always had on-the-spot conversion.)