Re: Japanese input in Linux environment (fcitx-mozc)

["ISHIKAWA,chiaki" <ishikawa@yk.rim.or.jp>]

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