On 2017/06/08 0:29, Eli Zaretskii wrote:
Date: Wed, 7 Jun 2017 10:02:06 +0200
From: Héctor Lahoz <hectorlahoz@gmail.com>
So I think the right direction is to look at the X input method
architecture. It seems there are some newer solutions like IBus or
SCIM. I can't tell how or up to what extent Emacs uses any of these.
https://en.wikipedia.org/wiki/X_Input_Method
Emacs uses XIM, has been doing that for a long time.
Surprise. I am a Japanese user of Emacs located in Japan.
I create my emacs binary with "--without-xim" all the time.
I use an emacs library that mimicks what XIM library would in terms of
talking to the conversion server,
and offers its own frontend inside Emacs buffer for phonetical input ->
Japanese Kanji Kana combination characters.
In my case I use English keyboard, a version of Happy Hacking Keyboard
and I use romanized Japanese input and conversion to Kana Kanaji string
from thereof..
This emacs libary for mimicking XIM and user interface for inputting
Japanese characters is called TAMAGO (tamago is "egg" in Japanese).
This should not be confused with another library for "git" support.
This input method *IS* antiquated, but like the original poster stated,
I got the habit of using this combination close to 30 years now and
can't switch easily.
Me --- English Keyboard
--- Emacs (this input method TAMAGO/egg .el library)
<---> phonetical string to
Kanji Kana string conversion server
(FreeWnn jserver with locally enhanced dictionary)
But how about entering Japanese for OTHER X-based applications such as
Mozilla firefox, and thunderbird under linux?
I use an XIM based input front end called kinput2-wnn-v3.1, which is
again very antiquated, but it DOES use XIM library of X11 distribution.
Me --- English Keyboard
|
kinput2-wnn -v3 front end <---> FreeWnn jserver
|
+-- application such as firefox/thunderbird
The use of TAMAGO .el library and kinput2-wnn makes the keyboard
combination to enter Japanese input more or less similar across Emacs
and other applications.
With TAMAGO we can define how romanized character input is done using
table-driven conversion, and it is the same with kinput2-wnn.
The operations of two input methods are close enough that, when the
operation differs from time to time, I got irritated. But usually such
difference is very small.
One difference is that the Japanese input using TAMAGO in Emacs happens
on the spot. I can choose on-the-spot or off-the-spot input using
kinput2-wnn. There used to be a few bugs related to on-the-spot input,
but I *think* they are gone, or I no longer care :-)
So I use on-the-spot input all the time. This makes Japanese input
uniform across Emacs+Tamago and other applications under X11.
The only hitch is that the mode indicator that shows which mode I am
using (Japanese and/or original ASCII input) is broken for
kinput2-wnn-v3.1 in the latest gtk library. It is shown as black rectangle.
http://myh.no-ip.org/~m-ito/diary/?date=201307
The above page refers to the library version .24, but the later library
also suffers from the same issue. I posted a patch but can't recall
where the patch is located in freedesktop bugzilla site.
Well, the Japanese input under Debian Linux using the
distribution-based input method works rather well.
But due to the old habit, I am using the above method by disabling
Debian's setup.
*HOWEVER*, obviously the input under OTHER OS, I mean, Window is very
different, and I am pretty disgusted at Entering many Japanese
characters under Windows. There does not seem to be an equivalent of
kinput2-wnn under Windows.
Often times, I create rough Japanese draft using Emacs under linux by
means of the above Japanese input method, and then only tidies up /
format the draft in MS Word under Windows if I am forced to work with MS
Word and other proprietary format.
So basically, I run linux inside Oracle VirtualBox under host Windows
for the last several years now for enjyoing the best of the both worlds.
There is one Emacs-lisp problem with TAMAGO input library.
It uses transparent / invisible property of characters (or region of
characters) when it handles user key input during conversion, and I
found it collide with the
use of such attribute in emacs's org-mode. Very unlucky thing.
With XIM, a bug was found about 4 years ago, which had been dormant for
15 years or so since XIM was proposed and implemented, and the bug made
it very difficult to use Japanese/Chinese/Korean input to
firefox/thunderbird, etc.when the bug surfaced when GTK library changed
its handling of event timestamp internally.
XIM library returned bogus timestamp which had been ignored until then.
But suddenly the bogus timestamp caused revised GTK library to misbehave.
We could not pull down menus any more, for example.
I am afraid when that happened, many users simply abandoned the XIM
frontend. The bug was fixed after a six months or so thanks to the help
of mozilla contiributor.
But I am afraid that the damage had been done.
I have no idea how many diehard TAMAGO + Emacs, and kinput2-wnn users
are there under linux who need to use FreeWNN jserver or commercial
Omron WNN Jserver with rich Iwanami dictionary for conversion. (I bought
one for circa 2000 linux. Unfortunately, I think the binary in a.out
format no longer runs due to some kernel change. Er, I should say that
the license server no longer runs. Oh, I forgot to mention. Sun, er,
Oracle Solaris still has Omron WNN Jserver with its rich dictionary and
so I can use Emacs with TAMAGO .el libary and/or kinput2-wnn-v3.1
frontend there very comfortably. I have an image of old Solaris 10 still
intact and it runs fine with Emacs + TAMAGO although I don't use it
often any more. Maybe testing program portability from time to time.)
I wish I could say "Hope this helps", but I am afraid that the above is
a working method that may not have much future (like 10-15 years only at
the maximum, or much shorter.)?
It would be interesting to learn where the OP settles for Japanese input
under linux when he/she is not bound by an antiquated input method and
can start afresh more or less.
TIA