個人的にはSKK + AZIK + CorvusSKK( https://github.com/nathancorvussolis/corvusskk )を長年愛用しているけど、残念ながら最近日本語入力をする機会が増えてきたので他のOSでも同様な環境をセットアップしたい。
CorvusSKKはWindows上のIMとして見ても素晴しい品質の実装で、学ぶべきところは多い。
ふつうの人のSKKと違うところ
職業柄、そもそも普通の人と違うconfigで生きていくべきでは無いんだけど一応MS-IMEのショートカットも頭に入ってるしイザとなったらちゃんと打てるから。。というわけでSKKにちょっとカスタマイズを入れて使っている。
ローマ字ルールはAZIKを採用 。AZIK( http://hp.vector.co.jp/authors/VA002116/azik/azikinfo.htm )は日本語でよく出現する音節に通常のローマ字から逸脱したキーストロークを割り当てている。拡張されるキーストロークには QWERTY配列を前提とした 幾何学的なルールを採用することで、習得と実際の入力を容易にしている。
| 通常の日本語よみ | ローマ字入力 | AZIK拡張されたローマ字入力 |
|---|---|---|
| しゃかいじん | sya kai jinn | xa kq jk |
| しょくどう | syo ku dou | xo ku dp |
| けってい | ke tte i | ke ; tw |
AZIKのようなコーディングは例えばCutKey( http://www.cutkey.jp/ )のような省スペースキーにも見られる。
促音に捨て入力を許可 。AZIKでは tt → たち のようなルールがあるため、 "使った" を通常のSKKのように入力すると、 tukaTta → 使たちあ のような変な入力になってしまう。CorvusSKKを始めとした最近のSKK実装では促音入力時の送り仮名に余った字がある場合にはそれを無視する仕様があるため、 tukaT;ta → 使った のように入力できる。通常のSKK + AZIKルールでは、 tuka+ta → 使った のように、AZIKの促音である ; → っ をシフトを押しながら入力する必要があり、106/101キーで別々のルールを登録する必要がある。
CorvusSKKでのAZIK実装の特徴
Corvus SKKはAZIKを想定したローマ字変換テーブルが付属してくる。このテーブルの由来はちょっと追い切れなかったが、個人的には良好なバランスの実装だと思っている。
xx での小書き入力 。 xxa → ぁ のように、 xx で小書きカナを入力できる。通常のIMEで見られるような、la → ぁ や xa → ぁ は、 l はSKKの英字入力用に使用され、 x は xa → しゃ のようにAZIKで使用されているためどこかに逃がす必要がある。CorvusSKKのテーブルでは、通常のローマ字入力の促音のように文字を重ねる方向にしている。さすがにそこまで入力する文字でも無いので3ストロークでも別に良いと思う。このルールはAquaSKKのAZIKテーブルにも存在する。
z の全角エスケープ 。 z[ → 『 や、z<Space> → <全角スペース> のような全角のエスケープは z のプレフィックスで統一されている。
CorvusSKKのカスタマイズ
更にCorvusSKKを以下のようにカスタマイズして使っている。 基本的にはTTYでも106/101キーを選ばずに使える ようなAZIK+SKK設定にしている。
qキーをカナ変換に使用 。SKKでは元々 q キーをカナ入力モード、AZIKでは q → ん に割り当てている。AZIKを採用したSKK実装は通常コレを @ (106キーの場合) や [ (101キーの場合) にリマップしているが、個人的な事情でキーボードが選べないケースが多いので差が出ないように q に統一している。これに伴い、"kq → あい" のようなAZIKルールは使えなくなってしまう。
| 日本語のよみ | 通常のローマ字 | 通常のAZIKルール | 今回の設定 |
|---|---|---|---|
| しゃかいじん | sya kai jin | xa kq jk | xa kai jk |
個人的には、 AZIKの良いところは通常のローマ字入力のスーパーセットになっているところ だと思っているので、SKKのキーバインドも可能な限り通常のキーバインドを使用したい。
ji → じ 、 jk → じん の入力 。CorvusSKKのテーブルでは、 zi → じ を標準の入力としているためか、 ji はデフォルトでは特に何も入力しない。 j の方がホームポジションに近いので個人的には ji を採用している。これをAZIK拡張し、 jk → じん も入れている。
x[ → 「 エスケープの削除 。CorvusSKKのデフォルトでは、 [ キーは101キーでのカナ変換用に予約されているためデフォルトでは何も入力しない。同様に101キー用に予約されているキーとして ' { もあり、これらはデフォルトでは何も入力せず、 x エスケープが必要になっている。カナ変換には q を使っているのでこれらのエスケープは不要となる。
Shift + Spaceでの有効化 。...あまり良いキーバインドでは無いが、個人的にはこれに慣れてしまっているので。。というわけで全角/半角キーではなく Shift + Space をIME有効化に設定している。
MacでAquaSKKを使う
AquaSKK ( https://github.com/codefirst/aquaskk ) はデフォルト直接入力が無い以外はおおむね満足できるSKK実装で、基本的に期待通り動作する。
ローマ字構成のカスタマイズにはGUIが無いが、単に azik.* を /Library/Input Methods/AquaSKK.app/Contents/Resources/ から /Library/Application Support/AquaSKK/ にコピーし、環境設定から選択すればカスタマイズが可能になる。
azik.rule はAquaSKKにバンドルされているSKK設定と同じ名前だが、特に被っていても問題ないようだ。
カスタマイズが必要なのは q をカナ変換に使用するための設定だけで、AquaSKKのAZIKでは q → ん を採用しているため、この設定を削除する必要がある
-
https://github.com/okuoku/myskkconfig/commit/1decc5cb8061a7a6a2e071d674fa3864e4ff84c6 -
qの特別操作を無効化したコミット
AquaSKKは、 ji → じ などはデフォルトで設定されている。
Ubuntu(Gnome-Shell) でのカスタマイズ
これがクソ難しい。。
X11やWaylandの日本語入力環境はクッソ激烈に実装が難しく、日本語入力は素直に諦めた方が良いと思う。iBusとibus-skkの組合せがよく使用されていて、ibus-skkはlibskkをSKKの実際の処理に使用している。このため、SKKの挙動はlibskkの方を設定してカスタマイズすることになる。
インストール
最近のUbuntuではiBusがデフォルトで使用されるので、単に ibus-skk パッケージを導入すればSKKは使用できる。
apt install ibus-skk
"設定"アプレットから "地域と言語" を選び、入力ソースの欄の + ボタンからSKKを追加できる。 "日本語"を選んだあとのキー配列はスクロールできる のに注意する。(最初は何故か出ないものだと思って手動で設定してしまった)
← スクロール可能
Ctrl + J 問題
SKKでは、ひらがなモードと直接入力モードの切り替えや、preeditの直接コミットに Ctrl + j を使う。しかし、X11のデスクトップ環境では、アプリが Ctrl + j をハンドルしているとキーイベントがそちらに吸われてしまうため、簡単な方法でこの組合せをIMEに渡すことができない。
とりあえず手元で編み出したのは:
-
Firefoxは諦める 。無理だった。
Ctrl+jは検索バーのフォーカスに割り当てられていて、これをIMEに渡せない。Chromiumは当然これを処理できるがこんな下らない理由でChromiumを使うことになるとは。。イベントキューからキーボードイベントが溢れている状況であれば入力がIMに渡るので、長押しするといつかはSKK側にキーが渡りひらがな入力に切り替わる。が、流石にそういう状況では使えない。。 (拡張を書いて排除する方法はあるが。。) - Waylandも諦める。いやホントこれみんなどうしてるんだろう。。waylandの拡張プロトコルは殆どがunstableに居て実装状況はどれもイマイチになっている。各種Wayland compositorで正常に動作する組合せはみつけられなかった。
-
Ctrl+@をとりあえずCtrl+jと同じように動作するようにlibskkを設定する。 - ターミナル類は AutoKey ( https://github.com/autokey/autokey ) を使い、
Ctrl+@を替わりに送出する。何故かAutokeyはターミナルに勝てる。
Autokeyのスクリプトは一行で良く、
keyboard.send_keys("<ctrl>+@")
を、 Ctrl + j にわりあてておけば、以後 Ctrl + j は Ctrl + @ に変換される。
大した問題ではないものの、GnomeではIMの切り替えを Shift + Space に設定すると、 もれなく Space もIM切り替えに割り当てられてしまう というとんでもない仕様があり(Cyclic逆順を shift でやるというUIルールのため)、スペースが入力できなくなってしまう。このため、 Shift + Space を切り替えに割り当てることは事実上できない。もっとも、通常のシチュエーションではSKKの直接入力モードで十分なため、IM自体をOFFにする必要性が無い。
ちなみにこの Ctrl + j がアプリケーションに吸われてしまう問題はMac上のAquaSKK( https://mzp.hatenablog.com/entry/2015/03/15/213219 )にもあり、こちらも Ctrl + j を別のキーに変換する手法を紹介している。
libskkの設定
.config/libskk/rules/azik-me のようなディレクトリを掘り、そこに /usr/share/libskk にあるデフォルト設定をコピーして変更する。
その後ibus-skkの設定パネルで選択する。
libskkにバンドルされているAZIKルールでも ji → じ のようなルールはデフォルトで装備されているので、カスタマイズは前述の Ctrl + @ でのひらがなモード切り替えだけになる。
かんそう
XIM/uim時代に比べて、X11というかLinuxの日本語入力環境はちょっと厳しくなりすぎなんではないだろうか。。Snapのようなsandbox化されたアプリケーションの時代になるともっと厳しくなっていくだろうし、Waylandのような新しいインフラへの対応が全体的に微妙なのも難しい。
もしかしたら、漢直WinやPOBox for Windowsのように、直接Unicode文字をWindowに送りつける実装の方が良いかもしれない。
「漢直Win」は、まっとうな IME ではなく、 WM_CHAR などのメッセージを送りつけることで文字を入力するという方法をとっています。
近年のセキュリティ状況を考えると、常識的なテキストサービスフレームワークが提供するような、周囲の文脈情報の提供といった高度な機能はセキュリティとのトレードオフでそれほど重要では無くなっていっているのではないかと思う。(実際MS-IMEのナチュラルインプットを真面目に活用していた人はどれくらい居るんだろうか)
こうして見てみると、CorvusSKKのAZIKテーブルだけが ji → じ を欠いている。いわゆる訓令式ローマ字では zi を採用しているし、通常はキーを左右の手に分散させるほうが好まれるが、未収録になっている理由は謎といえる。