Japanese input in Linux environment (fcitx-mozc)

Japanese input in Linux environment (fcitx-mozc)

[Maria Shinoto]

Hi,

I have been using a Mac over decades, but now I am preparing for a 
change to Linux, testing all software and setups on an old Lenovo 
Thinkpad with LinuxMint 18.1.

Emacs does not accept the Japanese input with fcitx-mozc, and there are 
some forum posts from which I could only learn that "it sucks". I did 
not found anything helpful.

Can anybody give me a hint into the right direction, how I could use 
Emacs with Linux and Japanese?

Thanks,
Maria

Japanese input in Linux environment (fcitx-mozc)

[Priv.-Doz. Dr. M. Shinoto]

Hi,

I have been using a Mac over decades, but now I am preparing for a 
change to Linux, testing all software and setups on an old Lenovo 
Thinkpad with LinuxMint 18.1.

Emacs does not accept the Japanese input with fcitx-mozc, and there are 
some forum posts from which I could only learn that "it sucks". I did 
not found anything helpful.

Can anybody give me a hint into the right direction, how I could use 
Emacs with Linux and Japanese?

Thanks,
Maria

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

[Emanuel Berg]

Maria Shinoto <maria@shinoto.de> writes:

> Emacs does not accept the Japanese input with
> fcitx-mozc, and there are some forum posts from
> which I could only learn that "it sucks". I did not
> found anything helpful.
>
> Can anybody give me a hint into the right direction,
> how I could use Emacs with Linux and Japanese?

Get in touch with the Emacs-w3m people at
gmane.emacs.w3m (or emacs-w3m@namazu.org) because they
are Japanese and it would seem they got their Emacses
up good enough :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[Lee B]

On 火,  6 06 2017, Maria Shinoto wrote:

> Hi,
>
> I have been using a Mac over decades, but now I am preparing for a
> change to Linux, testing all software and setups on an old Lenovo
> Thinkpad with LinuxMint 18.1.
>
> Emacs does not accept the Japanese input with fcitx-mozc, and there
> are some forum posts from which I could only learn that "it sucks". I
> did not found anything helpful.
>
> Can anybody give me a hint into the right direction, how I could use
> Emacs with Linux and Japanese?
>
> Thanks,
> Maria

I use ibus and mozc on Debian with no problems. Never used Mint, I'm afraid.

Lee.

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

[Eli Zaretskii]

> From: Maria Shinoto <maria@shinoto.de>
> Date: Tue, 6 Jun 2017 12:24:17 +0900
> 
> Emacs does not accept the Japanese input with fcitx-mozc, and there are 
> some forum posts from which I could only learn that "it sucks". I did 
> not found anything helpful.
> 
> Can anybody give me a hint into the right direction, how I could use 
> Emacs with Linux and Japanese?

Did you try the Japanese input methods built into Emacs?  I don't
read or write Japanese, so I don't know how adequate they are.

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

[source liu]

Hi，
   1. So, the fcitx is OK with the Desktop Environment?
   2. if 1,  please try emacs -nw under a terminal to see if the input works.
   3. if 2 works, please export LANG to you japanese LANG, IE. export
LANG=ja_jp.UTF-8 rather than en_US.UTF-8, then start emacs and try
again.
to my experience, emacs would ignore fcitx or ibus if the LANG is set
to en_US.UTF-8, but even though, emacs -nw under the terminal would do
the trick, or just set the LANG before start emacs
   you can have a try.



On Tue, Jun 6, 2017 at 1:40 AM, Lee B <lboc.home@gmail.com> wrote:
> On 火,  6 06 2017, Maria Shinoto wrote:
>
>> Hi,
>>
>> I have been using a Mac over decades, but now I am preparing for a
>> change to Linux, testing all software and setups on an old Lenovo
>> Thinkpad with LinuxMint 18.1.
>>
>> Emacs does not accept the Japanese input with fcitx-mozc, and there
>> are some forum posts from which I could only learn that "it sucks". I
>> did not found anything helpful.
>>
>> Can anybody give me a hint into the right direction, how I could use
>> Emacs with Linux and Japanese?
>>
>> Thanks,
>> Maria
>
> I use ibus and mozc on Debian with no problems. Never used Mint, I'm afraid.
>
> Lee.
>



-- 
Liu An
Institution of modern physics, Shanghai, China

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

[Jean-Christophe Helary]

> 2017/06/07 0:04、Eli Zaretskii <eliz@gnu.org>のメール:
> 
>> Can anybody give me a hint into the right direction, how I could use 
>> Emacs with Linux and Japanese?
> 
> Did you try the Japanese input methods built into Emacs?  I don't
> read or write Japanese, so I don't know how adequate they are.

They are good but require that you remember a method for Emacs and a method for the rest.

Jean-Christophe 

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

[Maria Shinoto]

Dear List members,

a lot of great hints, thank you all. I am living in Japan, it is 
morning, and I am following all directions at the moment.

In order to save your time, I write a short summary of the state now, 
and hopefully this evening or tomorrow, I can tell you what the result 
looks like.

1) The Japanese mailing list just answered, they told me how to use the 
Japanese input method from Emacs. It is clumsy, though, they do not 
recommend it themselves. Still, I have to test it; I could think of some 
additional caveats..

2) The LANG variable seems to be the problem, since I write on a 
basically German system with additional keyboard and language input. I 
will check this. Basically, I want to stay with a German system and 
write multilingual papers in Japanese or English mainly. Will test it 
all and report.


I think that sums it up, thanks a lot for now!

Maria




Am 07.06.17 um 08:44 schrieb Jean-Christophe Helary:
> 
>> 2017/06/07 0:04、Eli Zaretskii <eliz@gnu.org>のメール:
>>
>>> Can anybody give me a hint into the right direction, how I could use
>>> Emacs with Linux and Japanese?
>>
>> Did you try the Japanese input methods built into Emacs?  I don't
>> read or write Japanese, so I don't know how adequate they are.
> 
> They are good but require that you remember a method for Emacs and a method for the rest.
> 
> Jean-Christophe
> 

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

[Jean-Christophe Helary]

> 2017/06/07 8:54、Maria Shinoto <maria@shinoto.de>のメール:
> 
> 2) The LANG variable seems to be the problem, since I write on a basically German system with additional keyboard and language input. I will check this. Basically, I want to stay with a German system and write multilingual papers in Japanese or English mainly. Will test it all and report.

I have exactly the same issue. I write French, English and Japanese (albeit on a Mac system) and the difficulty to shift from an input system to the other is what keeps me on the Mac.

You may want to get in touch the the Tokyo Linux User Group (TLUG) they have a nice mailing list and they are generally extremely helpful.

Jean-Christophe 

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

[Emanuel Berg]

Jean-Christophe Helary wrote:

> I have exactly the same issue. I write
> French, English and Japanese (albeit on a Mac
> system) and the difficulty to shift from an
> input system to the other is what keeps me on
> the Mac.

French at least shouldn't be a problem on Linux
or Emacs. They have a few goofy chars just like
most languages. For example my Swedish have
Å, Ä and Ö. I have that as a compose key.
That way, I can have the programmer's
Anglo-American keyboard layout constantly, even
when I write in Swedish - i.e., the Swedish
Ö key on the keyboard still being ; - and
whenever I need the Ö I do

    Compose " o
    
Since getting that up, I've set up many other
goofy chars, some of which I believe are
present in the French language (I post this
last in this post) - I've done this mostly to
be able to write names correctly, e.g.
Éric de Bisschop.

It is *much better* to have the compose key for
the goofy chars than to switch the entire
keyboard layout!

    Facts for fans: The only national
    translation project of the man pages that
    had a huge body translated was the French.
    By now, French tech people are probably
    fluent enough in English tho.

How it works for Russian and Japanese I have
have no idea. The Russian alphabet is
different from the latin but it is still an
alphabet. So it should be straightforward.
Tho the "compose method" doesn't work because
the entire alphabet is just "goofy chars"!
So then you have no choice but to switch
between keyboard layouts.

You could put the Russian L at the same spot as
the latin L but it would be an uphill battle
and complete consistency impossible as there is
no equivalent for every char/sound. But perhaps
switching layouts between Russian and
Anglo-American isn't that big a deal as the
entire layout is switched, and because the
change is total, there is actually
not that much confusion?

With Japanese, is there an alphabet as well or
is it pictorial only? Or parallel systems?
How does a Japanese typewrite look?

Oh, the compose key in a Linux VT

    http://user.it.uu.se/~embe8573/conf/remap.inc

## Æ
compose 'A'  'E' to U+00C6 # Æ
compose 'a'  'e' to U+00E6 # æ

## Å
compose '0'  'A' to U+00C5 # Å - ring
compose '0'  'a' to U+00E5 # å
compose 'o'  'A' to U+00C5 # Å
compose 'o'  'a' to U+00E5 # å

## Ä
compose '"'  'A' to U+00C4 # Ä - diaeresis
compose '"'  'a' to U+00E4 # ä

## Ö
compose '"'  'O' to U+00D6 # Ö - diaeresis
compose '"'  'o' to U+00F6 # ö

## U
compose '/'  'U' to U+00DA # Ú - acute
compose '/'  'u' to U+00FA # ú
compose '"'  'U' to U+00DC # Ü - diaeresis
compose '"'  'u' to U+00FC # ü

## more As
compose '/'  'A' to U+00C1 # Á - acute
compose '/'  'a' to U+00E1 # á
compose '\\' 'A' to U+00C0 # À - grave
compose '\\' 'a' to U+00E0 # à

## C
compose '/'  'C' to U+0106 # Ć - acute
compose '/'  'c' to U+0107 # ć
compose '.'  'C' to U+00C7 # Ç - cedilla
compose '.'  'c' to U+00E7 # ç

## E
compose '/'  'e' to U+00E9 # é - acute
compose '/'  'E' to U+00C9 # É
compose '\\' 'E' to U+00C8 # È - grave
compose '\\' 'e' to U+00E8 # è

## I
## note: Linux VT + I/i + grave DNC
compose '/'  'I' to U+00CD # Í - acute
compose '/'  'i' to U+00ED # í

## O
compose '/'  'O' to U+00D3 # Ó - acute
compose '/'  'o' to U+00F3 # ó
compose '-'  'O' to U+00D8 # Ø - stroke (old name: slash)
compose '-'  'o' to U+00F8 # ø

## N
compose '~'  'N' to U+00D1 # Ñ - tilde
compose '~'  'n' to U+00F1 # ñ

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[Maria Shinoto]

Emanuel,

Thanks for the input. I already wrote Jean-Christophe personally, 
because it seems that we have a lot in common that is not a real issue 
for most of the people.

But since you took so much effort into the matter, which I really 
appreciate, some comments from my experience:

I write Japanese, English and German without looking on the keyboard 
with quite some speed. Using compose keys is inacceptable in that way. 
Instead, I change keyboard layout any time I change the language. This 
is a matter of two or one keyboard strokes, depending on the physical 
keyboard layout. I mainly use Japanese keyboards with Japanese and US 
layout (physically) and type on -- software-wise -- Japanese (Roman 
letters changing on the fly to Japanese), English, German, Korean and 
Chinese keyboard layouts. Since I can type blind, I am not distracted by 
the different writings on the physical keyboard keys.

I would not leave this technique behind, since it evolved during my 
life, together with computers getting smarter, and it is the most 
comfortable and the fastest way. I need the speed when writing down text!

So I am now looking along the route of the LANG variable; seems to be 
the most promising way. But for today, I will not have time to check 
this -- at the moment I am writing on my Mac :)

Best,
Maria


Am 07.06.17 um 09:43 schrieb Emanuel Berg:
> Jean-Christophe Helary wrote:
> 
>> I have exactly the same issue. I write
>> French, English and Japanese (albeit on a Mac
>> system) and the difficulty to shift from an
>> input system to the other is what keeps me on
>> the Mac.
> 
> French at least shouldn't be a problem on Linux
> or Emacs. They have a few goofy chars just like
> most languages. For example my Swedish have
> Å, Ä and Ö. I have that as a compose key.
> That way, I can have the programmer's
> Anglo-American keyboard layout constantly, even
> when I write in Swedish - i.e., the Swedish
> Ö key on the keyboard still being ; - and
> whenever I need the Ö I do
> 
>      Compose " o
>      
> Since getting that up, I've set up many other
> goofy chars, some of which I believe are
> present in the French language (I post this
> last in this post) - I've done this mostly to
> be able to write names correctly, e.g.
> Éric de Bisschop.
> 
> It is *much better* to have the compose key for
> the goofy chars than to switch the entire
> keyboard layout!
> 
>      Facts for fans: The only national
>      translation project of the man pages that
>      had a huge body translated was the French.
>      By now, French tech people are probably
>      fluent enough in English tho.
> 
> How it works for Russian and Japanese I have
> have no idea. The Russian alphabet is
> different from the latin but it is still an
> alphabet. So it should be straightforward.
> Tho the "compose method" doesn't work because
> the entire alphabet is just "goofy chars"!
> So then you have no choice but to switch
> between keyboard layouts.
> 
> You could put the Russian L at the same spot as
> the latin L but it would be an uphill battle
> and complete consistency impossible as there is
> no equivalent for every char/sound. But perhaps
> switching layouts between Russian and
> Anglo-American isn't that big a deal as the
> entire layout is switched, and because the
> change is total, there is actually
> not that much confusion?
> 
> With Japanese, is there an alphabet as well or
> is it pictorial only? Or parallel systems?
> How does a Japanese typewrite look?
> 
> Oh, the compose key in a Linux VT
> 
>      http://user.it.uu.se/~embe8573/conf/remap.inc
> 
> ## Æ
> compose 'A'  'E' to U+00C6 # Æ
> compose 'a'  'e' to U+00E6 # æ
> 
> ## Å
> compose '0'  'A' to U+00C5 # Å - ring
> compose '0'  'a' to U+00E5 # å
> compose 'o'  'A' to U+00C5 # Å
> compose 'o'  'a' to U+00E5 # å
> 
> ## Ä
> compose '"'  'A' to U+00C4 # Ä - diaeresis
> compose '"'  'a' to U+00E4 # ä
> 
> ## Ö
> compose '"'  'O' to U+00D6 # Ö - diaeresis
> compose '"'  'o' to U+00F6 # ö
> 
> ## U
> compose '/'  'U' to U+00DA # Ú - acute
> compose '/'  'u' to U+00FA # ú
> compose '"'  'U' to U+00DC # Ü - diaeresis
> compose '"'  'u' to U+00FC # ü
> 
> ## more As
> compose '/'  'A' to U+00C1 # Á - acute
> compose '/'  'a' to U+00E1 # á
> compose '\\' 'A' to U+00C0 # À - grave
> compose '\\' 'a' to U+00E0 # à
> 
> ## C
> compose '/'  'C' to U+0106 # Ć - acute
> compose '/'  'c' to U+0107 # ć
> compose '.'  'C' to U+00C7 # Ç - cedilla
> compose '.'  'c' to U+00E7 # ç
> 
> ## E
> compose '/'  'e' to U+00E9 # é - acute
> compose '/'  'E' to U+00C9 # É
> compose '\\' 'E' to U+00C8 # È - grave
> compose '\\' 'e' to U+00E8 # è
> 
> ## I
> ## note: Linux VT + I/i + grave DNC
> compose '/'  'I' to U+00CD # Í - acute
> compose '/'  'i' to U+00ED # í
> 
> ## O
> compose '/'  'O' to U+00D3 # Ó - acute
> compose '/'  'o' to U+00F3 # ó
> compose '-'  'O' to U+00D8 # Ø - stroke (old name: slash)
> compose '-'  'o' to U+00F8 # ø
> 
> ## N
> compose '~'  'N' to U+00D1 # Ñ - tilde
> compose '~'  'n' to U+00F1 # ñ
> 

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

[Jean-Christophe Helary]

> 2017/06/07 9:43、Emanuel Berg <moasen@zoho.com>のメール:
> 
> Jean-Christophe Helary wrote:
> 
>> I have exactly the same issue. I write
>> French, English and Japanese (albeit on a Mac
>> system) and the difficulty to shift from an
>> input system to the other is what keeps me on
>> the Mac.
> 
> French at least shouldn't be a problem on Linux
> or Emacs.

The problem is not typing French. The problem is that I use a JIS qwerty keyboard and that I use the same keyboard layout for all the languages I use.

At the moment there is no gnu/linux distribution that allows me out of the box to easily type French directly from the JIS layout and I don't want to learn a new layout to type French, I've used this one for 20 years already.

Jean-Christophe

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

[Emanuel Berg]

Jean-Christophe Helary
<jean.christophe.helary@gmail.com> writes:

> The problem is not typing French. The problem is
> that I use a JIS qwerty keyboard and that I use the
> same keyboard layout for all the languages I use.

Well, everyone uses a qwerty keyboard. And what does
it mean to be typing French? The French language has
the latin alphabet except for a few special chars that
are much more prominent in French, but are available
everywhere else nonetheless. And if it is not the
problem, what is the problem?

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 07, 2017 at 08:26:09AM +0200, Emanuel Berg wrote:

[...]

> Well, everyone uses a qwerty keyboard. And what does

I, for example, use a qwertz keyboard. Many French speakers use an
azerty keyboard (so, in Jean-Christophe's case, qwerty might be
seen as an exception).

All generalizations suck :)

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlk3pQcACgkQBcgs9XrR2kZShwCfXLOgFs+sqM64p88n2S9NmdF8
N2MAnRfhmwgBhYfZs2NrxYl8KAg2FGNF
=V65k
-----END PGP SIGNATURE-----

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

[Emanuel Berg]

<tomas@tuxteam.de> writes:

> I, for example, use a qwertz keyboard. Many French
> speakers use an azerty keyboard (so, in
> Jean-Christophe's case, qwerty might be seen as an
> exception).
>
> All generalizations suck :)

Well, they *are* the foundation of understanding.

Anyway this discussion has become too confusing...

As a programmer everything is or should be in
Anglo-American and the ; [ ] \ keys/chars readily
available. I suppose qwertz or qwerty doesn't matter
if that holds true. For example the Swedish layout is
qwerty to but has those important keys hidden (shift)
as those keys are the three special Swedish chars.

So it is a matter what to do as a non-computer person,
when still using the computer.

As for me, the compose key is optimal as the odd chars
out are only three, so to have the keyboard layout the
same for both languages is great. How many odd chars
there are in the French language I don't know; and it
is also a matter of how much you are a computer person
and how much you are a non-computer person using
the computer.

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[Héctor Lahoz]

Hi. Perhaps this should be a reply to the first mail but I lost it.
Sorry.

Just some thoughts about this. This is a very common problem. I wish I
could offer some specific solution but I can't since I don't write
Japanese. But I do write Spanish, English, German and occasionally
Greek and Cyrillic.

This task, change input between different languages, is not Emacs
specific. Emacs is not the only application in the world and probably
other applications will need this too. As I said it is a very common
task. So it should not be provided by Emacs itself but by some
underlying system, be it GTK, X11, or even the operating system.

Emacs should just communicate with that underlying system
and use its services.

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

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

[Emanuel Berg]

Héctor Lahoz wrote:

> This task, change input between different
> languages, is not Emacs specific. Emacs is
> not the only application in the world and
> probably other applications will need this
> too. As I said it is a very common task.
> So it should not be provided by Emacs itself
> but by some underlying system, be it GTK,
> X11, or even the operating system.

Yes, good point. Input methods should be the
same all across. However leaving Emacs out of
the equation may be too quick a conclusion.
Because there are more to inputs than chars.
For example, the cursor/point movement - M-b
for `backward-word' and C-a for
`move-beginning-of-line' and all that (there
are *tons* of those). When you get into using
all that producing and editing text or code
gets very fast. But then, when you use
a non-Emacs application you feel totally
crippled. For example if you have an external
IRC client (e.g., irssi), or even worse an
external mail client (e.g., Thunderbird).
To switch from one of those to an in-house
solution, which here most often would be ERC
and Gnus, one of the immediate huge gains would
be getting all those finger habits working
immediately, and contrary to many others things
it will require no configuration or anything
save for the switch itself.

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 07, 2017 at 10:02:06AM +0200, Héctor Lahoz wrote:
> Hi. Perhaps this should be a reply to the first mail but I lost it.
> Sorry.
> 
> Just some thoughts about this. This is a very common problem. I wish I
> could offer some specific solution but I can't since I don't write
> Japanese. But I do write Spanish, English, German and occasionally
> Greek and Cyrillic.
> 
> This task, change input between different languages, is not Emacs
> specific. Emacs is not the only application in the world and probably
> other applications will need this too. As I said it is a very common
> task. So it should not be provided by Emacs itself but by some
> underlying system, be it GTK, X11, or even the operating system.
> 
> Emacs should just communicate with that underlying system
> and use its services.
> 
> 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

Been there. It's more complicated. Yes, there are upsides to delegating
to X (and when I can, I truly do): entering stuff in a terminal or
a browser works the same than entering stuff in Emacs.

There are downsides too: Emacs input methods are much more flexible,
diverse and easier to set up.

Personally, I try to strong-arm X into doing my thing. That said,
I'm using pretty "plain" X, which is uncommon these days. I never
managed to completely figure out how those things are supposed
to work on more mainstream desktop environments (I support a couple
of Gnome installations). Perhaps I'd be less successful on those.

To sum up: for things I use semi-frequently, I go to the extra
length of "unified" configuration (i.e. outside of Emacs). For
very occasional things, it's Emacs input methods (much easier
to set up).

Sometimes (I started with greek a short while ago), I start with
Emacs, as a pioneer, and then try to rework my setup into a more
unified thing (e.g. setting up a second group by toggling via
double shift).

As for the compose key... for me, it's a boon, but I'd never
recommend it for often-used chars (I type much of German and
am grateful the umlauts got their keys, for example).

Emacs, of course, plays along with everything and then more.
Can't say how grateful I am for *that*

Cheers
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlk3uL4ACgkQBcgs9XrR2kaZ2gCfdjE/w7abuNajWkgiHB/iQgv1
IuUAn3POpmay1X/bDhnW4Tcmc2/TNtD4
=G1tH
-----END PGP SIGNATURE-----

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

[Emanuel Berg]

> Personally, I try to strong-arm X into doing
> my thing. That said, I'm using pretty "plain"
> X, which is uncommon these days

"plain" X, is that xterm and xpdf and the "x-"
suite of applications, and starting X manually
or semi-manually with xinit or startx and then
configuring the .xinitrc and .Xresources,
setting up keys with xbindkeys and so on?

If so, I do that as well. It is possible people
don't do that a lot.

I suppose (?) I have Gnome components somewhere
up and running as the only thing I did to get
it inhibited was disable the login manager and
instead launch what I want in X from .xinitrc.

I use X for LaTeX (PDFs), viewing pics, and
movies, that's all, and I don't need Gnome or
KDE for that.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Input methods (Emacs and others), plain X [was: Japanese input in Linux environment]

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 07, 2017 at 11:24:43AM +0200, Emanuel Berg wrote:

[changing subject, since only peripherally on-topic to thread]

> "plain" X, is that xterm and xpdf and the "x-"
> suite of applications, and starting X manually
> or semi-manually with xinit or startx and then
> configuring the .xinitrc and .Xresources,
> setting up keys with xbindkeys and so on?

Nearly. Xdm started at boot, session via window manager
(Fvwm). Pretty classic. Reached that point after a long
detour through Gnome and a short stay in XFCE.

> If so, I do that as well. It is possible people
> don't do that a lot.

That's my experience, yes.

> I suppose (?) I have Gnome components somewhere
> up and running as the only thing I did to get
> it inhibited was disable the login manager and
> instead launch what I want in X from .xinitrc.

That's the main difference between our setups, I think.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlk33iwACgkQBcgs9XrR2kYQBgCXfbaLHvTmae/Bf4NJP4QPKx0Z
XwCfReFt3252r+jK5vmSStCuBsAmiXE=
=aTbA
-----END PGP SIGNATURE-----

Re: Input methods (Emacs and others), plain X [was: Japanese input in Linux environment]

[Emanuel Berg]

> Nearly. Xdm started at boot, session via
> window manager (Fvwm). Pretty classic.
> Reached that point after a long detour
> through Gnome and a short stay in XFCE.

OK, Fvwm and Xfce. I use Openbox but the only
thing I do with it is Alt-Tab between windows
so I suppose I could do with whatever.
Actually if you have X and a WM the purpose of
a "desktop" eludes me - why do you want it?
To make everything have the same "look and
feel"? But isn't that what the GFX programming
library and WM do? I believe Gnome and KDE were
efforts when the Mac and PC (Windows) were big
on desktops - should be the Windows 95-era?
People that came to Linux didn't recognize it
to be a computer system and it made no sense to
them. However to then bring over the desktop
seems a bit illogical because don't people come
to Linux because they don't like what they had
before? Nowadays I suppose Gnome isn't even
a DE anymore.

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[Eli Zaretskii]

> 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.

Re: Input methods (Emacs and others), plain X [was: Japanese input in Linux environment]

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 07, 2017 at 04:51:44PM +0200, Emanuel Berg wrote:
> > Nearly [...]

> OK, Fvwm and Xfce. I use Openbox but the only
> thing I do with it is Alt-Tab between windows
> so I suppose I could do with whatever.

For me it does a bit more: hotkeys for Emacs client
windows for several purposes (one for taking quick notes),
for terminal, etc., several workspaces, battery state &
other small widgets, you name it.

> Actually if you have X and a WM the purpose of
> a "desktop" eludes me - why do you want it?

Well... horses for courses. All generalizations...
Some people like them. Why shouldn't they have
them? Myself, I have no use for a graphical file
manager. Others can't do without.

> To make everything have the same "look and
> feel"? But isn't that what the GFX programming
> library and WM do? I believe Gnome and KDE were
> efforts when the Mac and PC (Windows) were big
> on desktops - should be the Windows 95-era?
> People that came to Linux didn't recognize it
> to be a computer system and it made no sense to
> them. However to then bring over the desktop
> seems a bit illogical because don't people come
> to Linux because they don't like what they had
> before? Nowadays I suppose Gnome isn't even
> a DE anymore.

My significant one is a big GNU/Linux fan and uses
MATE. Choice is good :)

cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlk4X5gACgkQBcgs9XrR2kaVcACfZKwrt9hdaSJySlNqWVU/+KFe
0qQAn1b2ijt4x9XFxdO4ap8Mrzj2qUhZ
=R/3J
-----END PGP SIGNATURE-----

Re: Input methods (Emacs and others), plain X [was: Japanese input in Linux environment]

[Emanuel Berg]

> My significant one is a big GNU/Linux fan and
> uses MATE. Choice is good :)

Yes, the diversity is a strength and it is good
that some people dream big because once in
a blue moon they strike it big and something
new and wonderful appears.

As for me, I am at the other side of the
spectrum where I'd like to be so close to the
essentials being there all day everyday
sometimes I can discover how to cut one gram,
and of course no one will ever notice.

Some are white-collar scientists, some are
dreamers, and then there are obviously the
best, the blue-collar doers and engineers...
OK, I get it!

But I think you downgraded the discussion from
X, Gnome, and KDE. In a book I read that RMS
(rms) was involved. Gnome was to be for the
masses and KDE for the techno-druids. This is
all I remember and I don't remember the name of
the book either. It must have been good, but
I lost it somehow.

Still the purpose of the DEs isn't clear to me
- and they seemed to have grown into exotic,
underground hi-tech bases, run by criminal
masterminds! Not the least by incorporating
programs that was already existing
(e.g., gnome-screenshot, gnome-terminal - ?!).

Still we haven't touched upon Wayland, Mir,
or Unity.

-- 
underground experts united
http://user.it.uu.se/~embe8573

Re: Input methods (Emacs and others), plain X [was: Japanese input in Linux environment]

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Jun 07, 2017 at 10:40:46PM +0200, Emanuel Berg wrote:
> > My significant one is a big GNU/Linux fan and
> > uses MATE. Choice is good :)

[...]

> But I think you downgraded the discussion from
> X, Gnome, and KDE. In a book I read that RMS
> (rms) was involved. Gnome was to be for the
> masses and KDE for the techno-druids. This is
> all I remember and I don't remember the name of
> the book either. It must have been good, but
> I lost it somehow.

It's slightly different. The initial main impetus behind
GNOME was that the widget toolkit behind KDE, Qt, wasn't
Free at the time -- something which has changed long, long
time ago.

Then, of course, you had different tribes and what not. I
think that would be a really thrilling case study for an
anthropologist. Perhaps we can learn something from it.

> Still the purpose of the DEs isn't clear to me [...]

You've got to look into one to understand that, and be
it that, like me, you support it for someone else.

> Still we haven't touched upon Wayland, Mir,
> or Unity.

Different things.

But we're far, far off-topic by now. If no one complains
I propose to stop this thread or to take it off-list.

Cheers
- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlk5FPUACgkQBcgs9XrR2kY80gCeNbIpztJROqKNqTUxgLLgPviN
K4sAnRvPP9GozYaGDBI/O0rD3oDpaOYl
=8NFM
-----END PGP SIGNATURE-----

Re: Input methods (Emacs and others), plain X [was: Japanese input in Linux environment]

[Emanuel Berg]

> It's slightly different. The initial main
> impetus behind GNOME was that the widget
> toolkit behind KDE, Qt, wasn't Free at the
> time -- something which has changed long,
> long time ago.

Cute! That was it. Now I remember. This was
explained it the book as well.

> Then, of course, you had different tribes and
> what not. I think that would be a really
> thrilling case study for an anthropologist.
> Perhaps we can learn something from it.
>
> [...]
>
> You've got to look into one to understand
> that, and be it that, like me, you support it
> for someone else.

Long before I ever saw Gnome and KDE, I saw
Linux systems (or if it was BSDs or whatever)
that looked like desktop systems. They had the
xclock and tons of small windows scattered over
a high-resolution monitor, and basically every
window had the "x" prefix in the titlebar.

It didn't look as neat and polished as Finder
but not as tasteless as Windows. It was
a higher degree of hacker appeal despite being
a GUI.

Now what exactly is the difference between such
a paleo-graphical Unix system and a system that
has a desktop suite like Gnome or KDE?

Aren't DEs illogical no matter what one
thinks of them?

    OS > GFX system > ( terminal emulator )_WM > launch programs from shell

If if you aren't into shell/batch/text-based
computing but like GUIs with a "Start" menu
etc., doesn't that just translate into

    OS > GFX system > ( "Start" menu & file browser )_WM > launch programs by mouse-clicking

?

Obviously anyone can call their programs
whatever they want, including gnome-screenshot
and gnome-terminal. In a way, my very reasoning
could be applied to xterm and xpdf as well -
I mean, what's X about them? They are just
applications like any other that are
executable/viewable in X.

It is possible tho that the degree of
modularity and independence to software
development were different back then in that
that you actually had to adapt software at the
end of the line to the underlying X.

It is also possible it is just a phycological
thing to make big systems out of small
components, and try to force the components
into a fold that is common to all.

My "train" goes in the other direction, i.e.
the system is bigger than the component, but
hey, real trains are actually bi-directional as
long as they have two locomotives.

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[Maria Shinoto]

Just an update on my tests for Japanese input.

I did not find a solution yet. Here are my intermediate results:

- Emacs in the terminal works with Japanese (fcitx-mozc) flawlessly.
- It seems to be a problem with GUI Emacs not being able to use fcitx-mozc.

--> I did not test the elder combination ibus-mozc, but in winter, when 
I made my first test series, I had the same problem with this combination.

I read all of the posts in the list, thanks to you all for your help and 
thoughts. Just for the records:

Writing Russian of Greek or English or Spanish is essentially the same. 
It is different with CJK, i.e. Japanese, Chinese (Modern and Classical) 
and Hangeul/Korean. These languages write in two steps: input based on 
either sound or other varying rules and then a transformation to the 
correct characters, which have to be checked and confirmed by the writer.

If there is a wish to test GUI Emacs with East Asian Language scripts on 
Linux in order to get this fixed, I will be happy to be of assistance. 
For the time being, I will have to step back and wait for my next 
holidays to go on experimenting.

Maria



Am 08.06.2017 um 00:29 schrieb Eli Zaretskii:
>> 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.
> 

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

[Emanuel Berg]

Maria Shinoto wrote:

> - Emacs in the terminal works with Japanese
> (fcitx-mozc) flawlessly. - It seems to be
> a problem with GUI Emacs not being able to
> use fcitx-mozc.

Ha! This is the second time in a row that
terminal Emacs gets it right while the
GUI ditto doesn't, and both issues are
superficially unrelated (last time it was some
org-mode issue).

> If there is a wish to test GUI Emacs with
> East Asian Language scripts on Linux in order
> to get this fixed, I will be happy to be of
> assistance.

Yes, of course, do it!

> For the time being, I will have to step back
> and wait for my next holidays to go
> on experimenting.

My favorite Mao quote is you shouldn't let
school disturb your studies. I suppose the
adult version would be you shouldn't let work
obligations interfere with what's important for
you to do :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[Emanuel Berg]

Maria Shinoto <maria@shinoto.de> writes:

> - Emacs in the terminal works with Japanese
> (fcitx-mozc) flawlessly. - It seems to be a problem
> with GUI Emacs not being able to use fcitx-mozc.
>
> --> I did not test the elder combination ibus-mozc,
> but in winter, when I made my first test series, I had
> the same problem with this combination.

On a bigger note, this is really a *sad day* in Emacs
and all of Gnutopia!

How many people live in China, Japan, and Korea, and
how many use these languages in Asia and all over the
world? And guess what language group will play a huge
role in the future of software development if that
hasn't happened already?

But no matter how good the Asians are/will be it will
never be as classy as the West. Just as Shimano
components (Japan) and Giant frames (Taiwan) pale in
comparison with the Italian and French masters of
Campagnolo and Look. The Queen stays queen - adiós :)

-- 
underground experts united
http://user.it.uu.se/~embe8573

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

[Bruce V Chiarelli]

Maria Shinoto writes:

> Just an update on my tests for Japanese input.
>
> I did not find a solution yet. Here are my intermediate results:
>
> - Emacs in the terminal works with Japanese (fcitx-mozc) flawlessly.
> - It seems to be a problem with GUI Emacs not being able to use fcitx-mozc.
>
I use fcitx and I had the same problems getting it to work. I don't even
use an Asian language keyboard at all, but I had to set LC_CTYPE (not
LANG!)  to zh_CN.UTF-8 and the XMODIFIERS variable to get it working.

Could you try starting emacs like this (from a bash shell)?

$ LC_CTYPE=zh_CN.UTF-8 XMODIFIERS=@im=fcitx emacs

This is different from setting the LANG environment variable, and works
even if you don't have the zh_CN locale built or installed. Gtk will
print a warning, but it's harmless. (Documented here:
https://fcitx-im.org/wiki/Input_method_related_environment_variables)

--
Bruce V. Chiarelli

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

[ISHIKAWA,chiaki]

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

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

[ISHIKAWA,chiaki]

XIM mode indicator bug in gtk v3 library is not in freedesktop website, 
but at
https://bugzilla.gnome.org/show_bug.cgi?id=731190
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 
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é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
> 
> 
>