気がついたら2月でした。書き出しがほとんど前回と一緒なので、そのへんなんとかしたいところです。
さて、実は今回結構大きめの決断をしたので、なんでそれに至ったのかを書いていきます。まぁそこまで強い理由がある、というわけでもないのですが。
かな入力、やめました
今まで、 https://github.com/derui/oif こういうものまで作って色々かな入力を試してきました。実際に使っていたと思しきコミット履歴を見てみると、2013年とかになっているので、都合7年くらい前からですね・・・。
実際、ほとんどはマイナー配列に属するようなものばかりでしたが、それなりの数を使ってきました。
- 月配列
- 新下駄配列
- 蜂蜜小梅配列
- 薙刀式
この中で一番長続きして、かつ速度が実用に至ったのは、月配列と蜂蜜小梅配列です。どっちも秒間3〜4カナとかは普通にいけてました。ちなみに、上二つが中指シフト、下二つが親指でのシフトです。
しかし、これを書いている現在は、AZIK + SKKという組み合わせになっています。SKKは多分8年振りくらいに戻ってきました。AZIKはなにげに初めてですね。
なんでかな入力をやめたのか
これはいくつかの理由が複合しています。決してその配列に問題があるわけではない、ということは強調しておく必要があります。
- 親指の負荷が馬鹿にならないレベルになってしまった
- SKKとの相性が悪すぎた
- どうしても運指がローマ字入力の速度になってしまう
一つずつ少し深掘りしてみます。
親指の負荷
まず、私が使っているキーボードは、 Crkbd である、ということが前提にあります。このキーボードでは、一般的なキーボードよりも親指に色々機能を割り振ることを前提としたキー配置になっています。
詳しくは、私のキー配列を見てもらうとわかりやすいのですが、かなりの量の機能を割り振っています。
https://github.com/derui/qmk%5Ffirmware/blob/master/keyboards/crkbd/keymaps/derui/keymap.c
簡単に挙げると、
- LOWER/RAISEでの数字・記号の入力
- SandS/SandEnterによる、小指でのシフト全廃
- かな・英数のトグル
- ADJUSTに矢印やsway/i3用の定義が満載
という感じで、普通のUS/JISキーボードとは比較にならないレベルで機能を割り振っています。親指でのシフトを行うかな入力は、これに加えてシフトをしないといけないため、親指の負荷が半端じゃありません。
親指は強い指ではありますが、それは筋力が強い(元々は支持するための指なので)ということであり、ほかの4指に比べたら遥かに鈍いということもあります。実際、親指に機能を割り振りすぎたゆえに、親指に変な痛みが生じたのは一度や二度ではありません。
SKKとの相性
これは一言です。 親指シフト系統とSKKの相性は最悪 です。少なくとも私にとっては。SKK自体では、一応NICOLA/旧JISかなをサポートしてはいますが、それを参考にしてみた限りでは、とてもではないですがQWERTYでの書き味とは全く異なる、と言わざるを得ません。
SKKとの相性自体は、そもそもSKKを使わなければいいじゃん、という話もありますが。SKKは一回使うとクセになってしまうところがあるので、相性が悪いということが許せなくなってしまった、というのもあります。
大分四苦八苦してみましたが、最終的な結論としてはこうなりました。多分、親指の負荷が低い月配列や新下駄配列であれば、そこまでの問題にはならないんじゃないかとは思いますが。
運指速度の問題
これは、特に親指でのシフトをする配列で顕著でした。今迄20年以上使いつづけており、かつプログラムを書く際にもずーっと使いつづけているのがQWERTY、そしてローマ字入力です。このときの運指速度がデフォルトになってしまっており、これとかな入力時の運指速度がバッティングしてしまう、ということが度々発生していました。
同時打鍵を要求する配列は、仕組み上どうあがいてもローマ字入力に匹敵する運指速度になることはありません。名目の打鍵数が低いから問題ない、とする向きが強いですが、同時打鍵という仕組み上、実際には少なくない数の打鍵は2打鍵必要です。
このあたりで折り合いを付けられなくなった、という形です。
かな入力はダメだったのか
ある程度の速度にまでは到達できていましたし、実際には打っていて楽であった、ということもあります。なので、ダメだった、という二元的な評価ではありません。
単純に、合うか合わないかを実験してみた結果として、合わなかった、ということです。ブログでもなければ、プログラムを書く量の方が多い日もある、という事実もあるので、どちらにせよQWERTYの配列を変える方が余程効果がありそうですし。
AZIK + SKK
さて、AZIKですが、これはこれでSKKで使われる上で、いくつか問題がありました。
q
が潰される;
が「っ」になるので、switcky keyが使えないX
が「sy*」の接頭になるので、辞書の削除が使えない
これらをとりあえず解決してみました。こんな感じになります。
;; azikを利用するように
(setq skk-use-azik t)
(setq skk-azik-keyboard-type 'us101)
(require 'skk-azik)
;;; azikから追加された各種拡張を、SKK寄りに戻すための追加設定
;; 「ん」をqに割り当てるのは、ただでさえ負荷の高い左小指を酷使することになるので、元に戻す
(skk-delete-rule skk-rule-tree "q")
;; qの役割を元に戻したので、「も元に戻す
(skk-delete-rule skk-rule-tree "[")
;; Xで辞書登録する場合があるので、この場合でもちゃんと破棄できるようにする
(skk-add-rule skk-rule-tree '("!" nil skk-purge-from-jisyo))
(skk-add-rule skk-rule-tree '("q" nil skk-toggle-characters))
(skk-add-rule skk-rule-tree '("[" nil "「"))
SKKは、 skk-add-rule
とか skk-delete-rule
といった便利関数を提供しているので、こういうのが簡単にできます。注意としては、 skk-azik
は、何か関数を呼びだして変換ルールを設定しているわけではなく、requireされた瞬間に変換ルールを設定しているので、事後に追加したり削除したりしないといけない・・・ということです。
switky keyについては、元々SandS/SandEnterという形で、両手でSandなんとかを出来るようにしているのと、SandSに元々慣れ切っていた、ということもあるので、親指でのシフトでやるようにしました。
標準あるいは長いものに巻かれる
大分長い時間をかけて、最終的にはQWERTYの派生に戻ってきました。この期間を無駄ととるか、経験ととるかは人それぞれだとは思います。
色々な経験(firmwareで色々やったり、OCamlでシステムプログラミングしたり)もできたので、個人的にはプラスでしかないのですが。一回もかな入力をやったことのない人は、経験と思ってやってみるのもまた一興ではないかな?と思います。
SKKでも多少色々設定をしたりしているので、今度はその話も書ければ。そのときにまだSKKを使っていれば…。