From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: "ISHIKAWA,chiaki" Newsgroups: gmane.emacs.help Subject: Re: Japanese input in Linux environment (fcitx-mozc) Date: Sat, 10 Jun 2017 04:58:24 +0900 Message-ID: <40f0fdbe-f577-c082-401f-a0fc4cc521c8@yk.rim.or.jp> References: <834lvt9mxw.fsf@gnu.org> <20170607080206.GA3070@workstation> <83o9tz95pa.fsf@gnu.org> <37a042e3-a213-c783-7ff8-213326dfa7c8@yk.rim.or.jp> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1497038349 31015 195.159.176.226 (9 Jun 2017 19:59:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 9 Jun 2017 19:59:09 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Fri Jun 09 21:59:05 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dJQ3k-0007qf-Dk for geh-help-gnu-emacs@m.gmane.org; Fri, 09 Jun 2017 21:59:04 +0200 Original-Received: from localhost ([::1]:56224 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJQ3p-0004Kf-QD for geh-help-gnu-emacs@m.gmane.org; Fri, 09 Jun 2017 15:59:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJQ3D-0004JR-20 for help-gnu-emacs@gnu.org; Fri, 09 Jun 2017 15:58:32 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dJQ3A-0008EN-04 for help-gnu-emacs@gnu.org; Fri, 09 Jun 2017 15:58:31 -0400 Original-Received: from mail06.siriuscloud.jp ([219.118.72.6]:42843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dJQ39-0008Ce-Fe for help-gnu-emacs@gnu.org; Fri, 09 Jun 2017 15:58:27 -0400 Original-Received: from [192.168.0.111] (ntkngw435233.kngw.nt.ngn2.ppp.infoweb.ne.jp [61.121.54.233]) (Authenticated sender: ishikawa@yk.rim.or.jp) by access06.SiriusCloud.jp (Postfix) with ESMTPA id 3wktQ769y1z6639 for ; Sat, 10 Jun 2017 04:58:23 +0900 (JST) Authentication-Results: access06.SiriusCloud.jp; dkim=none reason="no signature"; dkim-adsp=none (unprotected policy); dkim-atps=neutral In-Reply-To: <37a042e3-a213-c783-7ff8-213326dfa7c8@yk.rim.or.jp> Content-Language: en-US X-Virus-Scanned: clamav-milter 0.99.2 at si-mail06 X-Virus-Status: Clean X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 219.118.72.6 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:113419 Archived-At: XIM mode indicator bug in gtk v3 library is not in freedesktop website,=20 but at https://bugzilla.gnome.org/show_bug.cgi?id=3D731190 you can look up the patch for v2 from the link in the above URL. That these bug reports are simply ignored shows how wide XIM is used all=20 over the world :-) TIA On 2017/06/10 4:49, ISHIKAWA,chiaki wrote: > On 2017/06/08 0:29, Eli Zaretskii wrote: >>> Date: Wed, 7 Jun 2017 10:02:06 +0200 >>> From: H=C3=A9ctor Lahoz >>> >>> 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. >> >> >=20 > Surprise. I am a Japanese user of Emacs located in Japan. >=20 > I create my emacs binary with "--without-xim" all the time. >=20 > I use an emacs library that mimicks what XIM library would in terms of=20 > talking to the conversion server, > and offers its own frontend inside Emacs buffer for phonetical input ->= =20 > Japanese Kanji Kana combination characters. >=20 > In my case I use English keyboard, a version of Happy Hacking Keyboard=20 > and I use romanized Japanese input and conversion to Kana Kanaji string= =20 > from thereof.. >=20 > This emacs libary for mimicking XIM and user interface for inputting=20 > Japanese characters is called TAMAGO (tamago is "egg" in Japanese). > This should not be confused with another library for "git" support. >=20 > This input method *IS* antiquated, but like the original poster stated,= =20 > I got the habit of using this combination close to 30 years now and=20 > can't switch easily. >=20 > 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= ) >=20 >=20 > But how about entering Japanese for OTHER X-based applications such as= =20 > Mozilla firefox, and thunderbird under linux? >=20 > I use an XIM based input front end called kinput2-wnn-v3.1, which is=20 > again very antiquated, but it DOES use XIM library of X11 distribution. >=20 > Me --- English Keyboard > | > kinput2-wnn -v3 front end <---> FreeWnn jserver > | > +-- application such as firefox/thunderbird >=20 > The use of TAMAGO .el library and kinput2-wnn makes the keyboard=20 > combination to enter Japanese input more or less similar across Emacs=20 > and other applications. > With TAMAGO we can define how romanized character input is done using=20 > table-driven conversion, and it is the same with kinput2-wnn. >=20 > The operations of two input methods are close enough that, when the=20 > operation differs from time to time, I got irritated. But usually such=20 > difference is very small. >=20 > One difference is that the Japanese input using TAMAGO in Emacs happens= =20 > on the spot. I can choose on-the-spot or off-the-spot input using=20 > kinput2-wnn. There used to be a few bugs related to on-the-spot input,=20 > 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=20 > uniform across Emacs+Tamago and other applications under X11. > The only hitch is that the mode indicator that shows which mode I am=20 > using (Japanese and/or original ASCII input) is broken for=20 > kinput2-wnn-v3.1 in the latest gtk library. It is shown as black rectan= gle. > http://myh.no-ip.org/~m-ito/diary/?date=3D201307 > The above page refers to the library version .24, but the later library= =20 > also suffers from the same issue. I posted a patch but can't recall=20 > where the patch is located in freedesktop bugzilla site. >=20 > 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=20 > Debian's setup. >=20 > *HOWEVER*, obviously the input under OTHER OS, I mean, Window is very=20 > different, and I am pretty disgusted at Entering many Japanese=20 > characters under Windows. There does not seem to be an equivalent of=20 > kinput2-wnn under Windows. >=20 > Often times, I create rough Japanese draft using Emacs under linux by=20 > means of the above Japanese input method, and then only tidies up /=20 > format the draft in MS Word under Windows if I am forced to work with M= S=20 > Word and other proprietary format. > So basically, I run linux inside Oracle VirtualBox under host Windows=20 > for the last several years now for enjyoing the best of the both worlds= . >=20 > There is one Emacs-lisp problem with TAMAGO input library. > It uses transparent / invisible property of characters (or region of=20 > characters) when it handles user key input during conversion, and I=20 > found it collide with the > use of such attribute in emacs's org-mode. Very unlucky thing. >=20 > With XIM, a bug was found about 4 years ago, which had been dormant for= =20 > 15 years or so since XIM was proposed and implemented, and the bug made= =20 > it very difficult to use Japanese/Chinese/Korean input to=20 > firefox/thunderbird, etc.when the bug surfaced when GTK library changed= =20 > 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 misbehav= e. > We could not pull down menus any more, for example. > I am afraid when that happened, many users simply abandoned the XIM=20 > frontend. The bug was fixed after a six months or so thanks to the help= =20 > of mozilla contiributor. > But I am afraid that the damage had been done. >=20 > I have no idea how many diehard TAMAGO + Emacs, and kinput2-wnn users=20 > are there under linux who need to use FreeWNN jserver or commercial=20 > Omron WNN Jserver with rich Iwanami dictionary for conversion. (I bough= t=20 > one for circa 2000 linux. Unfortunately, I think the binary in a.out=20 > format no longer runs due to some kernel change. Er, I should say that=20 > the license server no longer runs. Oh, I forgot to mention. Sun, er,=20 > Oracle Solaris still has Omron WNN Jserver with its rich dictionary and= =20 > so I can use Emacs with TAMAGO .el libary and/or kinput2-wnn-v3.1=20 > frontend there very comfortably. I have an image of old Solaris 10 stil= l=20 > intact and it runs fine with Emacs + TAMAGO although I don't use it=20 > often any more. Maybe testing program portability from time to time.) >=20 > I wish I could say "Hope this helps", but I am afraid that the above is= =20 > a working method that may not have much future (like 10-15 years only a= t=20 > the maximum, or much shorter.)? >=20 > It would be interesting to learn where the OP settles for Japanese inpu= t=20 > under linux when he/she is not bound by an antiquated input method and=20 > can start afresh more or less. >=20 >=20 > TIA >=20 >=20 >=20