Re: tlug: kinput2 vs. egg [was: Yatta! XEmacs Japanese input with kinput2 via XIM]

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

--------------------------------------------------------
tlug note from "Stephen J. Turnbull" <turnbull@example.com>
--------------------------------------------------------
>>>>> "Steve" == Steve Dunham <dunham@example.com> writes:

    >> Then when I figured that out, I knew from previous experience
    >> that you have to be careful about passing the areas to XOpenIC,
    >> and once I found those things were zero, it was that obvious
    >> thing to try.  Next I would give up :-)

    Steve> Yeah, but you took the time to actually sit down and do it.
    Steve> BTW, the only guy currently doing XIM stuff on XEmacs is
    Steve> working with Slowaris only (and he is working for Sun).

    Steve> Could you submit your bug report to
    Steve> <xemacs-beta@example.com> or give me permission to forward
    Steve> it?

Please do, if you don't mind.  You're welcome to quote anything I say
on TLUG to anybody, it's a public forum; but please reference me
(there's always an implicit copyright, but this is "fair use").  If I
say something so stupid as to be hilarious, and you want to quote
that, I would appreciate the courtesy of told just who is being shown
what a fool I can be :-)

When I get out from under the current logjam I'll join the XEmacs beta 
list, but at the moment I have no context to phrase the report properly.

    Steve> A good question to ask is what do people do who know
    Steve> Japanese and Chinese.  XEmacs and Mule handle internal
    Steve> representation and display (which XEmacs, IMHO, handles
    Steve> better) in a reasonable manner, but input is an issue.

XEmacs uses Mule to handle internal representation.  \what XEmacs
handles display better than is GNU Emacs.  (You knew that and
misspoke, I'm sure.)  You are absolutely right about handling the
internal representation well, though.  I wrote a little elisp function
to clean up MH-E scan listings (but only the RFC-1422 compliant
headers).  Version 0.1, which implemented parsing of RFC-1422 headers,
output mojibake as expected.  Version 0.2 simply filtered the two-byte
kanji codes generated by v 0.1 code with "(make-character lc-jp (aref
octets i) (aref octets (1+ i)))" and was immediately promoted to
version 0.8, because it worked!  (lc-jp is the leading character for
Mule's internal representation of Japanese - Mule represents non-ASCII
characters, maybe non-ISO-8859-1 characters, with a character set byte
prefix).  Boy, was I surprised.

XIM _can_ handle true multilingual input, but not as currently
implemented in XEmacs/Mule.  The current implementation of XIM
completely bypasses Mule.  The XIM is opened in the frame-opening
code, and does so based on the current C locale as found in LANG or
LC_ALL.  You can manipulate this with setenv (you need to get at the
process's environment, not the shell's) or whatever the XEmacs LISP
function is, but this would still require a separate frame for each
language.  /* NB: my understanding of the code is buggy; this doesn't
work.  Using setenv to reset LANG to C did not disable kinput2 in a
new frame. */

I don't know if there are proper hooks in Mule to attach to XIM
protocol input methods, but it should be possible to arrange for XIM
to be opened on the fly using code like that for attaching to Canna,
Wnn, or SJ3.  Then you would need some supporting C code to get a list
of available servers.  (Since LEIM/Quail is implemented entirely in
Emacs LISP, this is not an issue for LEIM.)  You could handle
key-binding to change language environments on the fly with single key
strokes or keep language state in a LISP variable and use a single
on-off toggle, or select from a menu, using standard Emacs LISP
techniques.  Preferably these should follow the LEIM interface, or if
that is considered clumsy, improvements in LEIM should be coordinated
with the improved interface for XIM methods.

This would also localize the bug-handling to the right place; if
opening the input method failed, you would default to ASCII.  Then the
user could try again.  As currently implemented, error-handling is
non-local in the sense that the XIM is opened with other X stuff,
which it is logically separate from, and not with Mule and input-
handling stuff, which it is logically related to.

    Steve> I've even had problems using Japanese and German at the
    Steve> same time.  I can't properly display by bookmarks file in
    Steve> Netscape.

This will get fixed when Netscape goes to Unicode (or to UCS-4, like
Mule is doing at the moment).  If it's a real problem, w3.el is the
only answer as far as I know.  If it's cosmetic, you can live with
it....

Allegedly Arena-I18N will do the job, but I can't even get to the
first title on www.gw.omron.co.jp, let alone download a full
distribution or even a full set of patches :-(

Regards,
Steve T.

-- 
                            Stephen J. Turnbull
Institute of Policy and Planning Sciences                    Yaseppochi-Gumi
University of Tsukuba                      http://turnbull.sk.tsukuba.ac.jp/
Tel: +81 (298) 53-5091;  Fax: 55-3849              turnbull@example.com
-----------------------------------------------------------------
a word from the sponsor will appear below
-----------------------------------------------------------------
The TLUG mailing list is proudly sponsored by TWICS - Japan's First
Public-Access Internet System.  Now offering 20,000 yen/year flat
rate Internet access with no time charges.  Full line of corporate
Internet and intranet products are available.   info@example.com
Tel: 03-3351-5977   Fax: 03-3353-6096