Re: [9fans] kbd.c

[okamoto@granite.cias.osakafu-u.ac.jp]

I have problem to understand the discussions here.  So, please let me
elaborate to state our situation more.

According to my understanding, there is a problem to solve various
keyoard only from dynamic loading of keyboard table.

In my ktrans, I set trigger key to 'Shift+Space' to translate 'hiragana' to kanji,
this is because this combination seems to have least chance to batting else.
However, there is no possibility to assign this combination to recognize from
any kind of printable character without changing kbd.c in  kernel.
You can see my kbd.c at http://basalt.cias.osakafu-u.ac.jp/plan9/kbd_106JP.c.
So, I assume there is some need to have a mechanism to change kbd.c
in kernel.  From this experience, I like Nemo's approarch.

There is another thing around keyboard and language problem.
I'm using English keyboard to enter Japanese, english and Russian or
Greek (The last two, I have no oppotunity though :-), using ktrans.
This case, we need only dynamic translation from English string to some
other language.  Ktrans offers that mechanism.  So, if the keyboard is fixed
we have no problem to deal with multiple languages in Plan 9.

I also have a notebook, which has Japanese JIS keyboard, and in this case,
the situation is simmilar to that of 'Shift+Space' above.  For an example,
Japanese JIS keyboard has some additional keys such as 'kanji' 'hankaku'
'hiragana' 'muhenkan', all of which related to Japanese input, and those
must be assigned by kbd.c in kernel.  Also, the key has different layout of
':' ';' '\' etc from those of English keyboard.   The latter case can be solved 
by both mechanisms, such those of kbd.c or some dynamically loaded 
translation table mechanism.

As a conclusion, if we could have a mechanism to change the default kbd.c 
dynamically like the Nemo's approach, I'd love to use it.

Kenji  --hope to help others not familier with kanji and kana culture...