マジで親指シフトする3秒半前

QMK でOASYSキーボード再現

Corne V4 Cherry上で親指シフトできるようにしたので、今回はこれを題材にしたいと思います。

Corne V4での親指シフト、ざっくりとした目的はおおきくふたつでした。

• 個人の親指シフト環境を構築したい
• ワープロ専用機OASYSの操作性を再現したい

なんですが、このサイトを訪れているほとんどの方にとって興味が持てるのは、私の環境などではなくOASYSのほうでしょう。

かつて、1980年代初頭に一世を風靡したものの、社会的な背景もあって歴史の闇に消えてしまったキーボード。そのOASYSキーボードの操作性を再現することは、わたしにとってもやりたいことのひとつだったのです。

ということで「試験に出る親指シフト」、”OASYS再現”という当面の目標を達成できたので、それを機に今回は総集編として書いてみました。

わたしは技術者でもプログラマーでもありませんが、WindowsXP の時代から自作エミュレーターで親指シフトをしてきました。ローマ字入力していた期間も短くはないですが、現役親指シフターです。

この記事はわたしとおなじように技術者でもプログラマーでもない人に向けて

• QMKファームウェアでどうやって親指シフトを実現したのか
• OASYSキーボードを再現するまでの経過
• OASYSキーボードの考え方

などを、まとめました。

Corne V4 + QMKファームウェアという具体例に沿って、いままで書いてきたことを総括したいと思います。

動作環境

なお、前提条件としてPCにはmacを使っていますが、本記事自体は特定OSに依存しません。

親指シフト以前

最初はかすかな期待でした。自作キーボードの多くがQMKファームウェアというものを使っていて、このQMKファームウェアというやつがかなり柔軟性が高いらしい、という情報を目にしたのです。

ひょっとして親指シフトできるかも、と考えました。

とうぜんのことながらQMKファームウェアにかんする知識が皆無だったので、ほんとうに親指シフト処理ができるのか、確かなことはわかりません。

QMKファームウェアにかんして情報収集するのであれば他のどこより公式ページが吉、ということのようでした。なので、公式サイトで親指シフトする方法をさぐりました。

で、とうぜんそうだろうとは思っていましたが、標準の機能だけでは親指シフトの実現は無理そうでした。

コンボ(Combos)のように親指シフトと考え方が近い仕組みもあるにはあったのですが……。

残念ながらコンボの枠組みをつかって親指シフトを実現するのは極めて困難だと判断しました。コンボと親指シフトとの違いはこちらで書きました。

ということで予想はしていましたが、どうやら自前で親指シフト処理を組み込むしかなさそうです。

そういえば、どこかのサイトでこんなことが書いてありました。

わたしもそう思いました。

EXCELなんかでもふつうに使っている限りはぜんぜん問題ないんだけれど、ちょっとセオリーから外れた使い方をしようと思うととたんに手間取ったりしますよね。アレのもっとすごいバージョンなわけです(先生、語彙力がぁ)。

ただ、そのことと相反するようですが、もともと自由なキー入力の実現を目指したシステムがQMKファームウェアなので、調べていくうちに親指シフトの実装はそれほどむずかしいものではなさそうだと、わかってきました。

親指シフトを実現するには？

最初の一歩は、親指キーのポジションのキーに、「あなたはこれから親指シフトキーですよ」と命名することから始めました。

これによってパソコン側が「関心感心、それではこれから親指シフトで文字入力できるようにしてさしあげましょう」ということになってほしかったのですが、

そうはいきませんでした。

「親指シフトキー？ 知らんよそんなもの」

というのがパソコン側の対応です。

それはそうだろうね、と思う方はここを飛ばしてつぎへすすんでください。

思わない方に向けて説明をつづけます。

なぜパソコンに、というか、もうすこしちゃんと書くとなぜパソコンのOSに親指シフトキーが無視されるかというと、OSはあらかじめ定義されたキーしか受け取れないからですね。

親指シフトキーは規格上存在しないキーなので、そのキーコードをパソコンに送っても「知らんよ」と言われてしまうわけです。

そのかぎりでいうと、たとえばmacのキーボードに備わっている[英数]キー、[かな]キーはmacのOSでは定義されているのでmac上では問題ありません。[英数]キーや[かな]キーを押せばIMEをオフにしたりオンにしたりといった動作をします。

でも、おなじキーコードをWindowsに送ってもやっぱり「知らんよ」ということになってしまいます。

なんですが

キーボードの規格(たとえばUSB-HID)では定義されていない、OSから見たら存在しないはずのキーであるにもかかわらず、わりと一般的というか、しばしばお目にかかるキーがあることをご存知でしょうか？

ノートパソコンなんかでお馴染みの[Fn]キーというやつです。

[Fn]キーというのは規格上では存在しないキーです。

このキーの値(つまりキーコード)をパソコン側に送ってもパソコンのOSは処理できません。

ではキーボード(内部のプログラム)側は何をしているのかというと、[Fn]キーの値をパソコン側に送っているのではなく、[Fn]キーと任意のキーとの組み合わせの結果を送っているのです。

たとえば[Fn]キーと数字の[ 1 ]キーを同時に押したら[F1] キーのキーコードをパソコンに送ります。[F1] キーはもちろん正規に定義されたキーですのでパソコンのOSは無事に受け取ることができる、というわけです。

と、ここまで書いてくるとお気づきの方もいるでしょうが、おなじ考え方が親指シフトにも応用できそうですよね。

もちろんFnキーと親指シフトキーの動作はまったく別物です。

たとえば親指キーのポジションにFnキーを配置したところで、それが親指シフトキーになったりはしません。でも、定義されていないキーを生かすという意味ではおなじ考え方が通用しそうですね。

親指シフトキーは規格上では定義されていませんが、キーボード側(のマイコン)で定義するのは自由です。そこで自分で定義した親指シフトキーと文字キーとの組み合わせの結果をパソコンに送ればいい、という考え方です。

たとえば[K]キーとおなじ右側にある親指シフトキーを同時に押すと「の」になるのが親指シフト配列ですから、その場合には[N]キー、[O]キーと連続した2キーをパソコン側に送ってやればいいと、そういうことになります。

キーボードのキーを押したとき、このキーを押しましたよ、という情報(キーコード)をパソコンに送る仕事をしているのが、キーボードのマイコンに収めるファームウェアと呼ばれるプログラムです。

とりわけ自作キーボードで使われることが多いのがQMK ファームウェアです。

Corne V4 CherryはQMK ファームウェアやその派生ともいえるVialに対応しています。
ということでQMK ファームウェアを使って親指シフト化をすすめました。

同時打鍵を判定する

さて、いちばんの要

同時打鍵かどうかを判定する処理です。

言い換えれば

どうやってOASYSキーボードの操作性を再現するか

です。

でも、これにかんしてはすでに答えが出ています。

「親指シフト・いんぷりめんと」に掲載したOASYSメソッドを忠実に(ひたすら愚直に)実行すればいいだけです。

「親指シフト・いんぷりめんと」のページで記述した処理は、日本語入力コンソーシアムの公式サイトが立ち上げられたとほぼ同時期に(1999年頃らしいです)アップされた「状態遷移表」とおなじものです。(現在は違う内容に書き換えられてしまいました)

しかしかつての「状態遷移表」こそはワープロ専用機OASYSの仕組みとも同等のものであることを「特許出願でわかったOASYSの親指シフト」という記事のなかで書きました。

その他モロモロの事情も加味して「OASYSメソッド」という表現を使うことにしました。

プログラムの骨子

ここは技術系サイトではないのでプログラムの概要というか、大枠のみにとどめてササッと書いてみたいと思います。

1，キーの入れ替え

QMK ファームウェアには、process_record_user()というキーを押したり離したりしたときのタイミングでフックできる強力な関数がありました。

たとえば、[A]キーが押されたらそのキー入力をインターセプトして[B]キーに変更したり、なにか特定の処理を加えたうえで[A]キーを送出したりといったことが、簡単にできてしまいます。

もちろん[A]キーと[B]キーを入れ替える、という程度のことであればREMAPとかVIAを使ったほうがずっと簡単です。でも、親指シフトの場合はもう一歩踏み込んだ処理が必要になるのでprocess_record_user() は欠かせない関数です。

2，時間(差)の取得

親指シフトを実現するうえで絶対に必要になるのが、正確な時間差の取得です。

文字キーを押したとき、親指キーを押したときの相対時間差で判定をおこなうので、時間を保持しておく必要があります。

本質的に必要なのはキーを押した時間です。親指シフトの処理ではキーの押し下げイベント、キーの押し上げイベントともに使うのですが、シフトありかなしかが微妙な状況での判定処理、コア領域においては、キーの押し下げイベントが決め手になります。ただし本来の親指シフト(つまりOASYSキーボード)での話ですが。

ちなみにprocess_record_user() の引数で使われるrecord構造体(record->event.time)にはキーを押したとき(及び離したとき)の時間が格納されているようです。

でも16ビットの分解能(uint16_t)であるため、親指シフト用途にはちょっと無理があります。16ビットとかわけわからないよ、という方は気にしなくても大丈夫です。細分化が足りないよ、という話ですので。

ほかに良さげなものがないかと探していくと、timer_read32()というものがみつかりました。

名前からわかるように戻り値は32ビット(uint32_t)、起動してからの経過時間をミリ秒単位で返す関数です。

これがあれば実用的な親指シフト環境がつくれそうです。

3，タイマー

キー入力をフックできて、キーを押したときの正確な時間差も取得できる、これで必要最低限の道具立てはそろったようです。

さらに上のふたつに加え、「必須ではないけれどできればほしいな」と思う機能がタイマーです。

探していくと、”start”から「どれだけ時間が経ったか」を返すtimer_elapsed32(start)という関数がみつかりました。

これでタイムアウト処理も実現できそうです。

以上で道具立てはそろいました。

QMKファームウェアという便利なツールが存在し、しかもキーボードとしての基本的な設定ファイル(rules.mk とか keyboard.json など)はCorne V4 の設計者であるfoostanさんが用意してくださっているので、原則的にはそのまま使わせてもらうことができます。

あとに残された私の仕事は「巨人の肩に乗る」

はずだったのですが

基本的なところで蹴つまづいたりして、じつのところ巨人の足元あたりをうろつき回っただけ、という気もします。

想像していたより時間がかかってしまいました。

とはいえ、なにはともあれ目的地にたどり着くことができました。

意図した通りOASYSキーボードの操作性、文字入力(の確実性)を再現できたと自負しています。

コーディングが素人っぽい？ 大丈夫です。問題なく親指シフトできていますので。

具体的に親指シフトを実現するためのuf2ファイルは、つぎの記事で公開します。

親指シフトの掟とQMKコンボとの違い

ここからは復習編です。

Corne V4 + QMKファームウェアで親指シフトすることができました。

そこで整合性をとる意味も含め、あらためて親指シフト(≒OASYSキーボード)の仕組みを、たとえばQMKファームウェアのコンボなどとくらべてどう違うのか、といった視点も含めて書いてみたいと思います。

まずは、親指シフトの掟3ヶ条です。以下はOASYSメソッドから必然的に導かれるロジックです。

親指シフトキーと文字キーが同時に押されたら、必ず「シフトあり」が成立する。

いま打った文字キーのシフト判定は、親指シフトキーを押した時間を基準とする。

一度押したシフトキーの作用が有効になるのはひとつの文字キーに対してだけ

掟その1 同時打鍵したらシフト成立

　親指シフトキーと文字キーが同時に押されたら、必ず「シフトあり」が成立する。

親指シフトを実現するために、けっきょくどんなことをしているのでしょうか。

答え

いま打った文字キーがシフトありか、それともシフトなしかを判定している。

直球勝負、どまんなかのストレートのような答えですね。

でも、そういうことなんです。

たとえば、シフトキーが押されているあいだに文字キーが押されたら？ シフトありでしょうか、それともなしでしょうか。

はい、シフトありですね。

どまんなかです。

だって親指シフトキーなんだから、です。

case on_thumb: // 親指キーセット状態で
    switch (event) {
        case Fig_Key_Down: // 文字キーが押された
            fig = key;
            send_key(fig, thumb); // シフトあり
            set_init(); // 初期化へ
            break;

※ 公開するUF2ファイルのソースコードより抜粋

プログラムのソースコードなど薬にもしたくないよ、という人でもコメントの部分(//の右側)を読めば、なにをしているかおわかりになると思います。

親指シフトキーを押しながら文字キーを押したら、その段階で「シフトあり」が確定しています。

ふつうの話ですね。

ところで、伝統的なShiftキーと違い親指シフトの場合は親指とほかの指を同時に押す、という操作を想定しています。

その場合、常に下図のようにはならないですよね。

同時のつもりであっても、じっさいには親指以外の指が先に押されてしまうことだってありえますよね。

この場合シフトありでしょうか？ それともなしでしょうか？

そもそも使い手は「シフトあり」のつもりで打って、”たまたま”文字キーを先に押してしまった、という状況を想定しています。

だったら「シフトあり」にしたいですよね。

掟その1では、「親指シフトキーと文字キーが同時打鍵状態になったら必ず『シフトあり』が成立する」はずでした。

それならシフトあり？

原則的にはそのとおり、シフトありです。

掟その2 シフトありの基準は親指キー

いま打った文字キーのシフト判定は、親指シフトキーを押した時間を基準とする。

ここで親指シフトの、仕組み側から見たときの考え方を、思い切りかんたんにいうと以下の文言に集約されます。

「シフトの守備範囲を広げよう」

です。

親指シフトキーが押されているあいだ文字キーが打たれたらもちろんシフトあり、でもそれだけじゃなくて、仮に先に文字キーが押されてしまった場合でも、「シフトあり」にしてしまおう。

シフトの守備範囲を広げてしまえばタイピングの誤差をすくい取ることができる。つまりキーボードをより楽に、意図した通りの文字を打てるようになるはずだよね、というのが親指シフトの根っこの考え方なんです。

この考え方をもとに、さらに親指シフト開発陣が探りあてた「同手シフトの発見」によりブーストがかかり、1980年代初頭の熱狂的なブームを生み出したことは「なぜ親指でシフトしたのか」のような過去記事で書いてきました。

なんですが

ではこんな場合はどうなるでしょうか？

文字キーが押されて、つぎに親指キーが押されて、どちらのキーも離されないまま、新たに文字キーが押されてしまいました。

最初に押した文字キーはシフトあり？ それともシフトなし？

ここで親指シフトの掟その2、です。

いま打った文字キーのシフト判定は、親指シフトキーを押した時間を基準とする。

親指シフトキーを押した時間を基準として、時間差の短いほうのどちらか一方のキーをシフトありと判定します。

ここが親指シフト処理のコアともいえる、「3キー分岐処理」になります。

具体的には

基準時間( = 親指シフトキーを押した時間)と、後から押した文字キーとの時間が短ければ、後から押した文字キーがシフトあり

基準時間と、最初に押した文字キーとの時間が短ければ、最初に押した文字キーがシフトありになります。

case fig_to_thumb: // 文字キー親指キーセット状態で
    switch (event) {
        case Fig_Key_Down: // 文字キーが押された
            // 3キー分岐処理
            if ((thumb_time - fig_time) >= (event_time - thumb_time)) {
                send_key(fig, 0);
                fig = key;
                send_key(fig, thumb); //ケース1
                set_init();
            } else {
                send_key(fig, thumb); //ケース2
                clear(thumb);
                set_fig(key, event_time);
                state = on_fig; 
            }
            break;

※ 公開するUF2ファイルのソースコードより抜粋
(無関係な1行削除)

掟その3 シフトは一度だけ

一度押したシフトキーの作用が有効になるのはひとつの文字キーに対してだけ

ところで

ここで出てくるだろう、とうぜんの疑問があるかと思います。

どちらの文字キーがシフト有効になるのか、という理屈はわかった。

じゃあシフト側の文字をつづけて打ち込みたい場合はどうするの？

ん、どうするの？

この疑問に対してかつての富士通技術スタッフは、さながら奥日光は華厳の滝の水が上から下へ流れ落ちるかのごとく、毅然としてまっとうな答えを用意したのです。

シフト側の文字をつづけて打ち込みたい場合は、親指シフトキーをもう一度押します(爆)。

えーっ

シフトキーと言ったくせにー、嘘つきじゃないか。シフトなのにー、シフトキー押しっぱなしで文字入力できないのはおかしいじゃネー

という批判は1980年代のむかしからあったのです。

でもシフトキー押しっぱなしを有効にしてしまうと、親指シフト処理の前提が成り立ちません。

上の図でいうと最初に押した文字キーが「シフトあり」に判定されたとしても、後から押したキーもつづけて「シフトあり」になってしまう可能性がでてきます。

だってシフトしているんだから、です。

書いたようにこの狭い宇宙では親指シフトキーを押した時間こそがただひとつの指標、判定基準です。

親指シフトキー押しつづけを無効にしないと、判定基準そのものが喪失してしまいます。

結果、後に押した文字キーはシフトなしのつもりだったのに、シフトありに判定されてしまう現象からまぬがれないのです。

ここでどれだけ小細工をほどこしても、シフトキーの押しっぱなしを有効にするかぎりグレーゾーンの発生は抑えられないんです。

そのむかし親指シフト開発スタッフはそういう判断を下したんです。(参考・「親指シフトキーボード」昭和54年(1979年)情報処理学会第20回全国大会 神田泰典 ほか)

そこで掟3が生まれました。

一度押したシフトキーの作用が有効になるのはひとつの文字キーに対してだけ

です。

以上、親指シフトの考え方、親指シフトの掟3ヶ条を紹介しました。

なお、シフトキー押しつづけに対する私感は最後にかきました。

親指シフトとQMK・コンボ(combos)との違い

ここでQMKファームウェアのコンボ(combos)と親指シフトとを比較してみましょう。

[A]キーと[B]キーを同時に押すと[Esc]キーを送信する、みたいなことをするのがコンボです。

[A]キーが先に押されても後から押されても有効化できるため、そういう意味では親指シフトと似ています。

ですが

結論を書くとコンボと親指シフトとは似て非なるものです。

コンボ自体はキーを押す順番を指定したり、タップのみに限定するなど細かな制御まで可能で、魅力的な機能だと思います。

でも、基本的には仕組みが違います。

具体的にいうと、あらかじめ設定しておいた絶対時間を基準に同時押しの判定をするのがコンボです。それにたいして、親指シフトは他のキーを打ったときとの相対的な時間差にもとづいてシフトのありなしを判定します。

いやいや、親指シフトだってタイムアウト処理をしているじゃないか、という意見も出てくるかもしれません。

でも親指シフトのタイムアウト処理はセンシティブなタイピング時においては同時打鍵判定に関与しません、というか、関与させてはいけません(「タイムアウト処理にかんする雑感」で後述)。

一方、QMKファームウェアのコンボでは規定時間(COMBO_TERM)以内に指定したキーが押されたかどうかで、同時打鍵を判定します。一般的には2キー(あるいは3キー)を指定することが多いと思いますが、3キーを上回る複数キーの組み合わせも可能なようです。その場合でも同時打鍵判定の理屈は2キー(ないしは3キー)のときとおなじです。

仮に[A]、[B]、2つのキーをコンボに設定し、さらに「define COMBO_TERM 40」みたいに再定義しておくと、40ms以内に[A]キーと[B]キーを押せばコンボ発動、みたいな感じになります。(標準は50ms)

一方親指シフトのほうは上でも書いたように今打った「その文字キー」がシフトありかなしかを、他のキーを打った時間との相対関係のなかで判定していきます。それが中核的な処理になります。

思い切り要約すると

コンボ ： 必要なのはタイマー(COMBO_TERM)

親指シフト ： 必要なのはタイムスタンプ(相対的な時間差)

ですね。

付け加えるとコンボの場合はレイヤーだとかモッドタップだとか、QMKファームウェアの仕組みや他の機能と協調する使い方に力点が置かれていますね。

タイムアウト処理にかんする雑感

親指シフトにおいてタイムアウト処理、本質的には「いらない子」です。

タイムアウト処理にかんしてもすでに過去記事で書いてきたことですが、あらためてとりあげます。

上で書いたように親指キーを押した、文字キーを押した、という相対時間差でシフトありなしを決めるのが同時打鍵を判定するコア領域(3キー分岐処理)になります。

言い方を変えると、「ここ一番という状況では絶対時間に頼らない」のが親指シフト(正しくはOASYSキーボード)の設計方針だともいえます。

絶対時間では個人差をすくい取れないからです。

なので、シフトありかシフトなしかの判定が微妙な状況において絶対時間(タイムアウト)が絡んでくるとまずいのです。判定を邪魔する方向に作用はしても、精度を高める方向に作用することは理屈上ありえないからです。これは仕組みの話です。

ここのところは一部のNICOLAユーザーさんが誤解している領域でもありますね。

そもそも富士通のIME・japanistで親指シフトする場合にはタイムアウト時間の設定項目すらなかったはずです。(無意味なので)

かつて親指シフトエミュレータとして一世を風靡した「親指ヒュンQ」なども、タイムアウト処理はしていないに等しかった、と記憶しています。

逆にいうと、もし親指シフトにタイムアウトの設定が必須だったとするならば、かつての親指シフトキーボードは未完成の状態で出荷されていたことになるわけですよ。そうなると手を叩いて喜ぶ人が出てくるかもしれませんが。

でも、んなこたぁ、ないです。運転は快適だけれど各ドライバーが工具を手にチューニング必須な車を、日本の自動車メーカーは売らないですよね。

親指シフトキーボードもおなじです。未完成でチューニングが必要なキーボードを当時の親指シフト開発スタッフが強引に販売に踏み切るようなことはなかった、と思いますよ。親指シフトが良いか悪いか、合うか合わないか、という話は横においといて、です。

かつてのNICOLA規格の記述にもやや不明瞭な部分があったとは思います。

上の表においても、キーの押し上げ処理とタイムアウト処理、役目ががほぼ被っているのです。

しかし、良くも悪くも「反応が鈍い」キーの押し上げイベントと違って、タイムアウト処理は間隔を狭めていけば確実に誤判定の要因になります。

というわけでそのむかし、まだ親指シフトの人気が高かった時代の話です。当時は親指シフトの技術面にも関心を持たれることが少なくなくて、見識の高い人のなかからは「タイムアウト処理いらない宣言」が出されたりしましたね。

理屈はそのとおり、見当違いの主張ではないと思います。

さて、上の主張が正論であることを認めたうえで、ここでちゃぶ台返しをしてしまいましょう。

それでもタイムアウト処理はあったほうがいい、とわたしは思います(爆)。

そうなんです。でも

「いいかい、この世に『いらない子』なんて誰もいないんだよ」

みたいな話ではありません。そうではなくて、一部のNICOLAユーザーさんがタイムアウトの設定にこだわる感覚が、わたしにはよく理解できるからですね。

書いたように

「タイマーが適切な時間に設定してあると、同時打鍵判定の精度が向上する」

ことはないです。もちろん使っているプログロムがまともな処理をしているならば、という条件がつきますが(ここは自戒を込めて)。

一方

「タイマーがほぼほぼ適切な時間に設定してあると、レスポンスがよくなる」ように感じる

のは、確かだと思うのです。

わたしはこれを

「キーを押したときにキーを押した気分を演出する効果」

と捉えています。

なのでわたしは「タイムアウト処理はあったほうがいいんじゃね」派です。

書いたように当サイトがひとつの指針としているのは上に掲げた表、つまり日本語入力コンソーシアムの公式サイトが立ち上げられたとされる1999年ころに、アップロードされた(と思われる)状態遷移表です。

この状態遷移表は「親指シフト・いんぷりめんと」のページで記述した処理とおなじものです。

1999年といえば、富士通は事業として親指シフトの可能性をすでに断念していただろうと、わたしは考えています。でも、だからこそ日本語入力コンソーシアム(の公式サイト？)に対して、完全に近いかたちで同時打鍵の判定ロジック提供に踏み切ったのだろうなあ、などと想像しています。

さて本題に戻ります。このNICOLA規格のなかには、タイムアウト時間を仮に100msecとする、みたいなニュアンスの記述がありました。

ややアバウトな書き方になっていた理由はここは正解がないところだからでもありますね。

でも100msecほど余裕があれば同時打鍵判定の精度を崩してしまう可能性はほぼゼロだと思いますし、キーを押したときのレスポンスも悪くないと感じます。

つまり私の経験上でもNICOLA規格が推奨する100msecは吉、という判断です。

たとえば仮にタイムアウト時間を倍の200msecとかにすると安全性は高くなりますが、キーの押し上げ時間のほうがふつうに早かったりするのでレスポンスは期待できません(つまり意味がありません)。

逆に半分の50msecとかに設定すると、同時打鍵の判定に絶対時間がおおきく関わってくるので、ひかえめに言って親指シフトとは違う処理系になってしまいます。よほど指先が器用な人はともかく、親指シフトする場合には意図する文字が出てこなくなる可能性が高い値になると思います。

ちなみにNICOLA規格でも同時打鍵判定の最小値として50msecまで許容していたようです。上述の「タイムアウト処理いらない宣言」はこのあたりから出てきていたのでしょう。(50msec前提ならば、私も「タイムアウト処理いらない宣言」に100万ペソ)

総合的に考えて100msecなら安全でかつ適切な値かと思います。

もちろん使う人によっては90msecがいいよとか、いやいや80msecでもぜーんぜんOKだぜぇと、笑顔で親指を立てる人がいるかもしれません。

でも、くりかえしになりますがここはこだわりポイントではありません。

ほどほど、でいいのです。

演出はあったほうがいいよね、という話ですから。

ということでわたしのプログラムでもタイムアウト時間はNICOLA規格の推奨値、100msec固定にしています。

シフトキー押しつづけ、いいの？

親指シフトキーといいながらシフトキーの押しつづけで文字入力できないのはおかしい、シフトキーの押しつづけを有効にするべきだという意見は、書いたようにはるか古代から言われつづけているんです。

この主張、そもそも論として親指シフトキーの押しつづけができたほうがいい、という前提に立っていますよね。

じつをいうと私自身も、親指シフトを覚えはじめのころにはシフトキーの押しつづけができたらいいなあ、と思っていた時期がありました。

たとえば親指シフト配列(NICOLA)では「なあ」というフレーズを打ち込むとき、どちらも左シフト側の文字なので左親指キーを連打しなければなりません。いちいち親指をキーから離さなければならないのは効率が悪いのではないかと、当時のわたしは考えていたんです。

でも現在は違います。

仮に技術革新がおきて親指シフトキーの押しつづけが有効になったとして、「あなたはシフトキー押し続けで文字入力しますか？」と問われたら、

わたしの答えはノーです。

仮にシフト側の文字がつづく場合であっても今まで通りのタイピング、つまり一文字ごとに親指シフトキーを押していくタイピングをつづけるでしょう。

その理由を簡単にいうと

親指シフトキーの押しつづけは手の運動負荷は抑えるかもしれないけれど、逆に心理的な負担は増やす、と考えるからです。

シフトキー 押し続けでの文字入力(から生まれる操作)は、「ヒトがものをつかむ」ような日常的な手の動きとは異なります。なのでそこに「技術の必要性」が生まれてしまう、と思うのです。

本来なら書く内容、コンテンツに集中したい状況で、非日常的な手の動きが入ってくると、その時点で注意力が分散し、結果として余計な負荷、ストレスが増える、と考えるんです。

特別な技術が必要なく、日常的な手の動きのままにタイピングできる、だからコンテンツに集中できるし、「考えながら書く道具」になる、「それが親指シフトっていう奴じゃねえのかい」などと考えています。

なので仮に、技術がすっごい進歩して親指シフトキーの押しつづけが有効になったよ、それに関してあなたはどう思いますか、と言われても

とくになんも思いませんけど

というのが正直な意見です。

これまで通りたんたんと親指シフトをつづけていくだけです。

以上、わたくしミツイの個人的な感想を書きました。

それでは良き親指シフトライフを。