趣味・娯楽

基本的なモード遷移をぜんぶ UHK 側の Fn なり Fn2 なりのレイヤーを使って行うようにするという乱暴な手でも解決できそう

Linux (というか libskk バックエンド) 環境であれば rules で勝手なキーを使えるので、なにかいい感じに普通のキーボードに非搭載になってそうなキーコードを探してきて使えばいい。
変換 と 無変換 は Hiragana と Latin あたりで使いたいので、 ひらがな/カタカナ キーに Shift か Ctrl の組み合わせをする (計4通り) とかが無難？
4通りあれば Wide Latin, Katakana, Hankaku Katakana への遷移には事足りる。

変換、無変換は普通の JIS 配列キーボードでは無変換が左親指で変換が右親指なので、それぞれ割り当ててやると良いか。
しかし親指の良い位置をそんなことに使うのも勿体なく感じるが……同時押しか長押しで Shift とか Ctrl としても使えるようにしてやれば少しはマシ？

nop_thread さんは #note-3 で書きました:

変換、無変換は普通の JIS 配列キーボードでは無変換が左親指で変換が右親指なので、それぞれ割り当ててやると良いか。

変換を始めるとき基本的に子音で開始する方が多いため、 Henkan 兼 Shift にするなら左手にある方が有利かもしれない。
しかし 変換 を左にすると他のキーボードを使うとき絶対に混乱する。(今更か？)
どうしたものか。

nop_thread さんは #note-3 で書きました:

しかし親指の良い位置をそんなことに使うのも勿体なく感じるが……

勿体なさで言うなら l で済むものに親指キーを割り当てる方が余程勿体ないか。

nop_thread さんは #note-2 で書きました:

なんなら Henkan がモード遷移にしか使われないのも勿体ない。仮名系のモード中は Henkan を Shift 相当にできれば嬉しい可能性がある (そうか？)

tap=Henkan(tap), hold=Henkan(tap)+Shift(hold) にすればモード遷移と変換開始を単一キーにまとめられるのでは？ と思ったが、これだと変換開始はいい感じにうまくいくが送り仮名等の開始で意図せぬ Henkan が挟まってしまう。
Henkan は今のところ commit コマンドにしているため送り仮名の前の preedit で確定されてしまう。

Henkan を commit でなくす手もあるが、そうすると今度は commit に何か割り当てる必要が出てくる。
C-m が commit-unhandled に、そして C-l とかが何故か commit になっており、これで良い気はしないでもないが、そもそも Henkan を commit にしているのは Hiragana モードへの遷移キーを commit にするとある意味一貫しているという理由もあるので、その性質を捨てるのは惜しい気もする。

どうせ左右の Shift は捨てられない気がするので、べつに Henkan はモード遷移 (羃等) と commit の2機能あるから十分に活用されているということで良い気がする。

nop_thread さんは #note-6 で書きました:

tap=Henkan(tap), hold=Henkan(tap)+Shift(hold) にすればモード遷移と変換開始を単一キーにまとめられるのでは？ と思ったが、これだと変換開始はいい感じにうまくいくが送り仮名等の開始で意図せぬ Henkan が挟まってしまう。
Henkan は今のところ commit コマンドにしているため送り仮名の前の preedit で確定されてしまう。

べつに送り仮名でまで使える必要はなく、 Latin からいきなり変換に突入できるだけでも便利のはず。
やはり欲しい。

https://github.com/TransitNow/uhk-agent-macro-gpt-prompt/blob/168b05786d5f49235bbb54def31b5e42acd32a36/macros.md#tap-once-for-a-key-tap-and-hold-for-another-key

数字キー等を長押しで F<n> キーになるのは便利そう。

追記: だめだった (→ #note-24)

左手の Shift の下部右側の Mod とかも全く使っていない。
LShift の下部左側の LSuper もよく考えると使っていない。
Mod が右手の一番良い位置にあるので全部そちらでやっており、 RSuper もその右隣で良い位置にあるのでそれで済んでいる。

Tips:

ifHold <COMMAND> は postponeKeys delayUntilReleaseMax 200 ; ifNotInterrupted ifNotReleased <COMMAND> で代替できる。
(→ 問題あり: #note-21)
(ただし <COMMAND> かその後でちゃんと postpone されていないイベントを発する必要がある。)
hold timeout のデフォルトは 200 (ms) だが、後者の形式で書けばグローバルな hold timeout とは独立して自由に調整できる。

home row mods という概念を知ったが、 https://mastodon.cardina1.red/@lo48576/115079670226464139 のとおり懸念があるのでたぶんやらない。

Esc を modifier として使って同時押しすることは基本的になさそう (かつ他のキーと重なるほど高速に打つ場面もそうなさそう) なので、親指 Esc は dual role にできそう。

nop_thread さんは #note-8 で書きました:

数字キー等を長押しで F<n> キーになるのは便利そう。

数字キーの double tap からの hold で primary role (つまり数字キー) 長押し扱いにすべきか悩んだが、以下の理由から結局やめた。

• 数値の桁数は非常に重要なので、数字を連打する機会はそうそうない。
  どうしても連打で我慢できないほど沢山打ちたい場合はコピペか vim 等を使うだろう。
• 現状のセットアップ (tap は digit、 hold は F<n>) だと double tap まで待たずに済むので、数字キーを連打してもキーを離した時点で数字が入力される。
  しかし double tap primary を有効にしてしまうと、連打の2回目が tap か hold かによって1回目の押下が tap だったか hold の prefix だったかが決まる。
  つまり数字の入力が、最初の押下から1回分以上遅延する。さすがにこの遅延は気持ち悪い。

F<n> はたまに必須ながら頻度は低いので、 Mod+digit や digit 長押しで打てるのに最上段を占有させておく意味は薄い。
最上段も何か活用したいところ。
どうせ最上段の Esc も遠すぎて使ってないし。

今のところ使っている F<n> の一覧:

• F2
  • GUI ファイラでのファイル名変更
    • 利便性のために事実上必須
• F3
  • 再検索
    • ごく稀にしか使わない
  • GUI ファイラ (pcmanfm) での左右ペイン分割
    • ごく稀にしか使わない
• F5
  • ブラウザやファイラでの表示更新
    • C-r で代用可能
• F6
  • ブラウザでのロケーションバーとコンテンツ領域の間でのフォーカス移動
    • ロケーションバーへの移動は C-l で代用可能だが、戻ってくるのが Tab 連打などになり面倒なので事実上必須
• F12
  • tuigreet ログインマネージャでのシャットダウン/再起動メニュー
    • 代替キーを知らないのでおそらく必須

レイヤーについて:

今のところ Mod レイヤーは基本的に破壊的な効果の小さいキー (典型的にはナビゲーション系のもの) を集めており、 Fn レイヤーには破壊的な効果の大きい (典型的には文字、Delete、Bksp) を集めている。
とはいえ Fn に置くものが少なすぎて (まともに使っているのは Delete, Bksp, PrintScreen, キーマップ切り替えしかない) あまりに無駄なので、これも何か考えたいところ。

とはいえ Mod+h (on Dvorak layout) で ← にしていて Fn+h で Bksp にしていたり、 Mod+s で → にしていて Fn+s で PrintScreen にしていたりなど、普段使いしているものが微妙に位置被りしているため、それをどうにかしないことには統合も難しい。
PrintScreen などべつにどこにあろうが大した問題ではないが (なんなら UHK 80 の右側キーと最上段が余っているのでそこに tap で割り当てても良いくらいだ)、 Mod+h と Fn+h は重度に活用しているため非常に悩ましい。
カーソル移動をホームポジションの1段上にずらして Mod+gcrl にする手もあるが、そもそも Mod+h は Vim の hjkl に合わせてこの位置に置いてあるものなので、さすがに譲れない。
Fn+h は一部のアプリ等が C-h を奪っていく場合に (あるいは非 GTK 系でそもそも C-h を削除にできない場合に) C-h と近い感覚で削除をできると嬉しいのでここに置いてある。
これも h と同じ場所にあることが重要なので移動には慎重になってしまう。

nop_thread さんは #note-17 で書きました:

レイヤーについて:

今のところ Mod レイヤーは基本的に破壊的な効果の小さいキー (典型的にはナビゲーション系のもの) を集めており、 Fn レイヤーには破壊的な効果の大きい (典型的には文字、Delete、Bksp) を集めている。
とはいえ Fn に置くものが少なすぎて (まともに使っているのは Delete, Bksp, PrintScreen, キーマップ切り替えしかない) あまりに無駄なので、これも何か考えたいところ。

基本的に副作用の有無や強さに関係なく、キーの押下 (あるいはせいぜい modifier と他のキーのコンボ) は全部 Mod に持ってきて、普通のキーの挙動の範疇に収まらないマクロ等を Fn 系レイヤーに持っていくのは悪くない使い分けな気がしている。
こうすると押しやすさの面でも Mod だけ優遇しておけばよく Fn は二の次にできるので考えやすいかもしれない。

RShift の右 (Enter の下部右側) はホームポジションから打とうとすると誤爆しやすいため、ここに記号等を置くのはあまり良くない。
やはりキーボード右下の矢印キーの隙間を埋めるような左右対象な何らかの機能を置いておくのが良さそう。
(UHK 80 のデフォルトでは Alt+← または Alt+→ になっているが、これは trackball module の History Backward/Forward 等の方が使いやすいのでいらない。)

nop_thread さんは #note-10 で書きました:

Tips:

ifHold <COMMAND> は postponeKeys delayUntilReleaseMax 200 ; ifNotInterrupted ifNotReleased <COMMAND> で代替できる。
(ただし <COMMAND> かその後でちゃんと postpone されていないイベントを発する必要がある。)
hold timeout のデフォルトは 200 (ms) だが、後者の形式で書けばグローバルな hold timeout とは独立して自由に調整できる。

問題が発覚した。
たとえば postponeKeys delayUntilReleaseMax 200 ; ifNotInterrupted ifNotReleased tapKey f12 ; tapKey = としたとき、 press e, press ], release e, release ] の順でイベントを発生させても、キーボード側からは press e, press ], relaese ], release e の順でイベントが発射されてしまい、OS 側に e が長押しと認識されて連打扱いになってしまうことがある。

nop_thread さんは #note-21 で書きました:

nop_thread さんは #note-10 で書きました:

Tips:

ifHold <COMMAND> は postponeKeys delayUntilReleaseMax 200 ; ifNotInterrupted ifNotReleased <COMMAND> で代替できる。
(ただし <COMMAND> かその後でちゃんと postpone されていないイベントを発する必要がある。)
hold timeout のデフォルトは 200 (ms) だが、後者の形式で書けばグローバルな hold timeout とは独立して自由に調整できる。

問題が発覚した。
たとえば postponeKeys delayUntilReleaseMax 200 ; ifNotInterrupted ifNotReleased tapKey f12 ; tapKey = としたとき、 press e, press =, release e, release = の順でイベントを発生させても、キーボード側からは press e, press =, relaese =, release e の順でイベントが発射されてしまい、OS 側に e が長押しと認識されて連打扱いになってしまうことがある。

postponeKeys まわりを弄ってみたり tap ではなく press と release に分解してみたりいろいろ試してみたが、 key release の順序を変えられないのはどうしようもなさそう。
尤もタイピングにおいては基本的に keypress しか見ていないはずなので、この点自体が問題とまでは今のところ考えていない。
問題の本質は、 press = が確定するまでの待機中に release e も保留されてしまうこと。
delayUntilReleaseMax はマクロを起動したキーが release されるかタイムアウトまで待ってしまうので、「別のキーが release されたので、メインのキーが release されていないしタイムアウトもしていないが delay をやめる」ということができない。

これは delayUntilReleaseMax を postponeKeys で修飾してしまっているせいだが、この postpone は普通のキーが後から押された場合の対応に必要。
具体的には、この postpone をなくして delayUntilReleaseMax 200 ; ifNotInterrupted ifNotReleased tapKey f12 ; tapKey = としている場合、 press =, press e, release =, release e のように打った際に press e, press =, release =, release e のようなイベント列として発出され、 =e と打ったのに OS 側には e= として出ていってしまう。
これは絶対に許容できない。

nop_thread さんは #note-22 で書きました:

問題の本質は、 press = が確定するまでの待機中に release e も保留されてしまうこと。
delayUntilReleaseMax はマクロを起動したキーが release されるかタイムアウトまで待ってしまうので、「別のキーが release されたので、メインのキーが release されていないしタイムアウトもしていないが delay をやめる」ということができない。

タイムアウトを短くする手もあるが、そもそも数字キーは F<n> キーとして使うのはメインではないため、発動しやすくするのは誤爆防止の面でもあまり望ましいと思えない。

ちなみに OS 側は xset r rate 200 50 (Xorg の場合) で設定しているので、 key repeat 発動まで 200 ms の遅延、発動したら 50/s のリピートとなっている。

nop_thread さんは #note-8 で書きました:

数字キー等を長押しで F<n> キーになるのは便利そう。

結局、文字のように振る舞うキーに2種類の non-modifier なスキャンコードを割り当てるのはタイピング体験への悪影響が大きすぎる (遅延が大きくなったり key repeat 発動までのラグを小さくしづらい等) ので避けることにする。
F<n> は素直に Mod+<n> (あるいは Mod+何か or Fn+なにか) で打てば良い。

nop_thread さんは #note-24 で書きました:

結局、文字のように振る舞うキーに2種類の non-modifier なスキャンコードを割り当てるのはタイピング体験への悪影響が大きすぎる (遅延が大きくなったり key repeat 発動までのラグを小さくしづらい等) ので、避けることにする。

うまくいかなかった実装の供養:

postponeKeys delayUntilReleaseMax $fnnumHoldTimeout
ifNotInterrupted ifNotReleased final tapKey f10
tapKey 0

nop_thread さんは #note-12 で書きました:

Esc を modifier として使って同時押しすることは基本的になさそう (かつ他のキーと重なるほど高速に打つ場面もそうなさそう) なので、親指 Esc は dual role にできそう。

Esc を特定回数高速連打することはありそうなので、 modifier としての同時押しは良いとしても連打を邪魔しないよう注意する必要はある。

nop_thread さんは #note-28 で書きました:

しかしタイピングがメインでしかも vim であることを考えると、ナビゲーションに方向キーや C-f, C-b 等は特に必要としていない気もする。

どうやらそうでもなかった。
まず vim でないブラウザや他アプリ等で左方向キーはよく使う。
そのうえ、 vim でも左方向キーは typo 修正や括弧飛ばしなどいろいろな場面でよく使う。
つまり方向キーくらいの小さなナビゲーションはテキスト入力において頻出なので、できれば同じレイヤーか同等に操作しやすいレイヤーに入れたい。

左手の親指が実質 Space と日本語入力有効化の専用になっていることに慣れており、左手の Space の左のキー (現状では Fn) がかなり使いづらい。
慣れの問題かもしれないが……。

逆に右手の親指の Mod が使いやすいのは良いとして、その右にある Super は結構使い慣れているため、本当はこれを他の layer キーにすべきなのかもしれない。
いくら tiling WM を使っているからといって、さすがに Super が良い位置を使いすぎでは……？
とはいえホームポジションから移動することなく Shift キーも同時に活用してウィンドウの切り替えや移動やレイアウト変更やターミナルの起動ができるのは、実際便利ではある。
小指で最下段を押していてはこうはいかない。

「A」の左の Ctrl が勿体ない気がしたので、というより正確には「特定のショートカットを期待しており Ctrl+something を期待していない場合」がたまにあることに気付いたので、これもマクロで別物にしてどうなるか試してみている。
基本的には modifier として振る舞い、 Fn3 に何か割当があればそれを使い、ない場合は Ctrl の同時押しとして機能するようにしてある。
(ダブルタップホールドすると生の Ctrl として振る舞うようにすることで、本当に Ctrl そのものが必要な場合のフォールバックとしている。)
マクロが少々荒削りで期待どおりの挙動にならない場合はあるが、結構うまくいっているので期待できそう。

今のところ具体的には、 {smart-ctrl}+m は C-m でなく Enter に、 {smart-ctrl}+h は C-h ではなく Backspace に、 {smart-ctrl}+d は C-d ではなく Delete とするという3つの割当が Fn3 に入っている。
ただし C-d を奪ってしまうと Vim でのスクロールやターミナルでのシェル等からの脱出に微妙に支障があるため、どうしたものか検討中。

そもそも modifier としての機能をレイヤーでなくマクロで実現する (しかも単に modifier として振る舞わせるだけでなく組み合わせの結果にまで干渉する) というのがかなり無理のある実装らしいということに気付いてきた。
しかも smart ctrl については press Ctrl → press h → press c → release h → release c のような綺麗な直列でない入力に対しての振舞や実装を考えるのが面倒すぎる。
smart ctrl はおとなしく Fn3 layer をそのまま使うのが良さそうか。

そもそもレイヤー丸ごと利用にしなかったのは base layer をコピーしてきて ctrl フラグを立てて回るのが面倒だっただけなので、挙動に関する動機ではない。

バグってる smart ctrl マクロ供養:

// NOTE: Buggy!
ifDoubletap final holdKey leftControl

begin:
postponeKeys {
    // Wait for the next another key.
    // FIXME: Unexpected loop happens here when
    // saved key is pressed too long.
    // Maybe because the key release event being
    // discarded outside the loop? idk.
    ifNotPending 1 ifNotReleased goTo $currentAddress
    // If released, break the loop and do the finalization.
    ifReleased goTo release
    // Save the key to wait for its release later.
    setVar smartCtrlSavedKey $queuedKeyId.0
    //setLedTxt 200 "get queued key $smartCtrlSavedKey"
    toggleLayer fn3
    ifKeyDefined $smartCtrlSavedKey setVar smartCtrlLayerActive 0
    else {
        // Not defined in fn3 layer. Use Left Control as a modifier.
        setVar smartCtrlLayerActive 1
        untoggleLayer
        pressKey leftControl
    }
}
// Wait for the pending event to be processed.
ifKeyPendingAt 1 $smartCtrlSavedKey goTo $currentAddress
// Wait for the current (non-smart-ctrl) key to be released.
ifKeyActive $smartCtrlSavedKey goTo $currentAddress

// Clean up for the temporary activation of a layer or a modifier.
if ($smartCtrlLayerActive) releaseKey leftControl
else untoggleLayer

// Repeat until the smart ctrl key is released.
goTo begin

release:
// No finalization required.

nop_thread さんは #note-35 で書きました:

smart ctrl はおとなしく Fn3 layer をそのまま使うのが良さそうか。

そもそもレイヤー丸ごと利用にしなかったのは base layer をコピーしてきて ctrl フラグを立てて回るのが面倒だっただけなので、挙動に関する動機ではない。

single tap (hold) で Fn3、 double tap (hold) で Ctrl になるようにしてみたが、これはこれで Mod との組み合わせで面倒があるかもしれない。
Mod-h で Backspace になっているのを Fn3-Mod-h で Ctrl-Backspace にしたいが、 Mod layer の A の左を Ctrl にすると Mod, Fn3, H で Ctrl-Backspace にできるが、 Fn3, Mod, H だと Backspace だけになってしまう。
マクロ側で対処可能か？

……こういうことを考えていると、 layer よりもマクロで振り分けできた方が良い気がしてきてしまう。
本当にどうしたものか。

nop_thread さんは #note-35 で書きました:

そもそも modifier としての機能をレイヤーでなくマクロで実現する (しかも単に modifier として振る舞わせるだけでなく組み合わせの結果にまで干渉する) というのがかなり無理のある実装らしいということに気付いてきた。

やはりこれだった。
というか、マクロか否かによらず「Ctrl や Shift のような modifier の状態を実際の物理キーの状態と直結させず操作する」というのがかなり筋が悪い設計らしいということに気付きはじめた。
A の左の Ctrl が良い位置にあって勿体ないところまでは事実だが、だからといってこれを Ctrl のようなそうでもないような特殊なキーとして定義しようとしたのが良くなかった。
A の左は素直に Fn3 などの別レイヤーにして、さらには Mod+Fn3 などについても別レイヤー Fn4 等として用意するのが妥当な気がしている。

nop_thread さんは #note-38 で書きました:

A の左の Ctrl が良い位置にあって勿体ないところまでは事実だが、

とはいえ左小指を使う以上は両手と組み合わせる可能性のあるタイピングの場面で使うには相性が悪く、この辺りはやはり Ctrl とか Super のような二軍の修飾キーにしておく方がマシそうだし、この2つなら Ctrl の方が良い。
素直に Ctrl のままにしておくか。
マクロで苦労 (マ苦労) するのではなく、C-h や C-d や C-m を使う手癖をなおして Mod-h,d,m を使うようにするのがたぶん正攻法。

nop_thread さんは #note-29 で書きました:

nop_thread さんは #note-28 で書きました:

しかしタイピングがメインでしかも vim であることを考えると、ナビゲーションに方向キーや C-f, C-b 等は特に必要としていない気もする。

どうやらそうでもなかった。
まず vim でないブラウザや他アプリ等で左方向キーはよく使う。
そのうえ、 vim でも左方向キーは typo 修正や括弧飛ばしなどいろいろな場面でよく使う。
つまり方向キーくらいの小さなナビゲーションはテキスト入力において頻出なので、できれば同じレイヤーか同等に操作しやすいレイヤーに入れたい。

方向キーを Fn レイヤーに入れていたが、 Mod-h の Bksp との併用が特に多く、別レイヤーにあると効率が悪い。
方向キーは Mod に入れるべきだろう。

そうなると、 Mod-h を Bksp にして Mod-g を Left にするか、 Mod-h を Left にして Bksp を別のところに移動するかが問題。

nop_thread さんは #note-40 で書きました:

そうなると、 Mod-h を Bksp にして Mod-y を Left にするか、 Mod-h を Left にして Bksp を別のところに移動するかが問題。

他に良いキーが思い付かない。
空いていてそこそこ押しやすいものでいうと Mod-u とかだが、覚えられる気がしない (mnemonic にするのを諦めて体で覚えるべきなのかもしれないが)。
とはいえ実際ブラウザ等でも Mod-h より C-h を使ってしまう頻度の方が高いので、実は大して Mod-h にこだわる意味もなさそうではある。
しかし U かぁ……

nop_thread さんは #note-40 で書きました:

そうなると、 Mod-h を Bksp にして Mod-g を Left にするか、 Mod-h を Left にして Bksp を別のところに移動するかが問題。

Mod-g は Escape を置くのに悪くないのではと思っていたので、 arrow で潰すのもそれはそれで少々惜しい気がしている。
まあ親指が Mod から離れられないことを考えると上の段の人差し指位置は意外に使い勝手が良くないので、そんなに勿体なくもないかもしれないが。
(それはそれで Left を置いておくにはどうなんだという話もある。)

nop_thread さんは #note-42 で書きました:

空いていてそこそこ押しやすいものでいうと Mod-u とかだが、覚えられる気がしない (mnemonic にするのを諦めて体で覚えるべきなのかもしれないが)。

backslash と vertical bar を mod layer の押しやすい場所に置いてみる実験をしていたが、位置を忘れて迷うことがかなり多かったので、押しやすさは二の次で必然性 (あるいは良質な mnemonic) は事実上必須と考えている。
仮令必然性のない場所に体を慣らすことができたとて、今度は割当を変更したり移動したりができなくなって将来余計に困る可能性が結構あるので、あまり無茶はしたくない。