OyayubiKE: Karabiner-Elements 14.10.0 でmacOS上の親指シフト環境を構築する2022

2022-10-05

Karabiner-Elements (KE) を 14.10.0 にバージョンアップしたところ, だましだまし使っていた自前の親指シフト環境が使えなくなってしまった.

そこで今回, 以前リリースしたものを思い切って全面的に見直し, 新たにOyayubiKE
と称することとした. 一応使えるレベル (完成度は自己評価で51％くらい) にはなったと思うので公開する.
が……後述のように 一定の不具合は存在するので注意すること.

OyayubiKEの動作確認した環境

動作確認した環境は以下の通り:

• ハードウェア環境
  • Mac本体: Mac mini (M1,2020)
  • USB Hub: ELECOM 2x7 USB switch U2SW-B27SBK
  • USB Keyboard: Logicool K120 (ごく一般的な日本語JIS 109キーボードです)
• ソフトウェア環境
  • OS macOS Monterey 12.6
  • IME 日本語入力プログラム（Kotoeri）
  • Krabiner-Elements 14.10.0
• 動作確認したソフト
• ブラウザ - Safari, Brave.
• エディタ等 - ターミナル.app, ターミナル上のvim, Visual Studio Code (+vscodevim).
• その他アプリ - Libre Office (Writer), Discord, League of Legends.

OyayubiKE 使い方

まず, IMEのユーザ辞書登録で,「だくてん」「はんだくてん」「かんま」「ぴりおど」の読みで,　それぞれ「゛」「゜」「,」「.」などと登録をしておく.

また日本語入力プログラムの設定で「Caps Lockキーで最後に使用したラテン語系入力ソースと切り替える」を, チェックしてオンにしておく. これはシステム環境設定 > キーボード, 入力ソースタブから, 左ペインの 日本語 - ローマ字入力 を選択するとウィンドウの下部に出てくる.

次に設定ファイルをダウンロードして設定を行う.

1. OyayubiKE (JSONの設定ファイル2つ: OyayubiKE-muhenkan_henkan-ime_kotoeri-2022.json と OyayubiKE-NICOLA-2022.json) を, ダウンロードする
2. ホームディレクトリ以下にあるディレクトリ ~/.config/karabiner/assets/complex_modifications/ に, ダウンロードしたJSONファイルを配置する
3. Karabiner-Elementsを起動し, Preferences... の Complex Modificationsで, 以下の3つを Enable (許可) する:
   1. OyayubiKE-muhenkan_henkan-ime_kotoeri-2022 > OyayubiKE escapeでescape, input_sourceをRoman+en, Oyayubi-Modeをリセット
   2. OyayubiKE-muhenkan_henkan-ime_kotoeri-2022 > OyayubiKE Oyayubi-Mode/Any/L/R
   3. OyayubiKE-NICOLA-2022 > OyayubiKE NICOLA配列 2022
4. Karabiner-Elementsをリスタート

OyayubiKE の左シフトキーは無変換キー(japanese_pc_nfer), 右シフトキーは変換キー(japanese_pc_xfer)である. IMEは, macOS標準の「日本語入力プログラム」(Kotoeri) を使った. これらは他のキーやIMEの値に編集し直すことで,　設定で変えることができる.

配列は基本的には NICOLA配列 だが, 以下の点は変えている:

• ん キーの右は規格では何もないが, OyayubiKEではバックスペース・キー(delete_or_backspace) を配置
• 「゛」「゜」(濁点と半濁点) は, スラッシュキーの右にあるバックスラッシュキー (international1) に配置

—-

処理内容の概要の解説

現在公式で配布されているNICOLA配列 (Japanese NICOLA, Japanese NICOLA example) は, シフト判定を, from のイベント内に simultaneous を記述することで行なっている.

これらとは違い, OyayubiKEでは, 親指シフトの状態を管理するための4つの変数を導入することでシフト判定を行う: それぞれOyayubi-Mode, Oyayubi-L, Oyayubi-R, Oyayubi-Any である. これにより, なめらかなタイピング感覚を得られていると思う.

• Oyayubi-Mode 親指シフトのモードの状態. 1 なら親指シフトモードオン, 0 なら親指シフトモードオフ. 左シフトキーが押下〜 単独で 右シフトキーが押された後に離されるまで1となる. それ以外では0となる. オンであるときのみ, 親指シフトのリマップがなされる.
• Oyayubi-L 左シフトの状態. 1 なら左シフトオン状態, 0ならオフ状態. 左シフトキーが押下されたとき1となり, 離されたとき0となる.
• Oyayubi-R 右シフトの状態. 1 なら右シフトオン状態, 0ならオフ状態. 右シフトキーが押下されたとき1となり, 離されたとき0となる.
• Oyayubi-Any いずれかのシフトの状態. 1なら左か右シフトオン状態, 0ならいずれのシフトもオフ状態.

—-

既知の不具合とその対応・解決について

(1) macOS-KE間のIME状態の同期不具合

画面の表示上 (右上のアイコン) は, IMEが「ひらがな」となっているのに確定済みアルファベットしか入力されなかったり, 「A」(keylayout.ABCまたはKotoeriの英字モード) となっているのに親指シフトの配列で文字が出てしまう現象が, ときどき発生する. この現象を以下, KEの「入力ソースハマり状態」あるいは単に「ハマり状態」と呼ぶ.

こんなときはおもむろに, 左シフトキーかESCキーを1回ポチッと押してみて欲しい.
Oyayubi-Mode の値がゼロにリセットされ親指シフトモードから抜けて, プレーンな通常の入力に戻る.

• IMEのアイコン表示が「あ」の場合は右シフト,　「A」の場合は左シフトを何度か押す,
• 右シフトと左シフトを何度か交互に押す,
• ESCキーを何度か押す,

もしくは,

• Caps Lock を何度か押してIMEのアイコン表示のモードに入り直す

などして欲しい.

分析と考察

入力ソースのハマり状態の不具合はDiscord, League of Legendsのクライアントおよびゲーム本体, まれにVSCodeなどでしばしば確認された (これらはすべてElectronベースのアプリである). ターミナルでもときどき発生する.

ハマり状態のとき, Karabiner-EventViewer で Variables を確認すると, "input_source" の値が固定されてしまっている。画面の表示上IMEの入力ソースが変わっていても, 値は EventViewer の変数には反映されない.

私がテストしたところ, どうやらハマり状態は, アプリを切り替えて使うことを繰り返していると発生するようだ.

客観的には, KEのIME状態の認識とmacOSの実際のIMEの状態との間に, 齟齬が生じてしまっているかのように見える. 調査を進めたところ, Carbon由来の TISSelectInputSource の不具合 (Workaround for CJKV input sources switching ) というのがあるらしい.

このハマり状態の回避のために, 変数 Oyayubi-Mode を導入した. これはinput_sourceの値とは別に, KE側でIMEの状態を保持・参照するためのものである. 親指シフトキーの押下や離すタイミングで更新される.

(ところが, ごく稀に Oyayubi-Mode の更新が行われなくなることがある.
Oyayubi-R, Oyayubi-Lの更新は行われているのに…
記述ロジック上そんなことは絶対に起こらないはずだが起こるのである.
設定ファイルの編集中に起こるような気もするが, 原因は不明である.)

(2) 既存のテキストを編集時に変な文字列の入力される

親指シフトキーでjapanese_eisuu, japanese_kanaを送出しないことで解決済み.

分析と考察

これはエディタで, 既存のテキストを編集している際にしばしば起こる現象であった.

カーソル位置の前に確定文字列がある状態で, 親指シフトキーを押下した場合に発生する. 具体的には, 入力した日本語文字列を確定させた状態で右シフトキーや左シフトを押すと, 確定された文字列がローマ字に戻ってしまう.

これは客観的には, 日本語入力プログラムの再変換が機能してしまっている現象に見える. このため, 親指シフトキーからのjapanese_kana, japanese_eisuuの送出は止めることとした.

左シフト, 右シフトで japanese_eisuu, japanese_kanaの送出をやめたら

今度はターミナル.app上での日本語入力がうまくいかなくなってしまった. 具体的には:

• 左シフトキー (NFER) で select_input_source してもIMEが「英字」(またはオフ) にならない - japanese_eisuuを送出していないから当然
• 日本語入力モードがオンになっているにもかかわらず, 確定状態のローマ字が入力されてしまう - japanese_kana の送出をしないバージョンでは, 文字列が確定された状態で右シフトを押しても, KE内部でIMEがオンにならないようだ.

select_input_sourceのプロパティのフル指定

select_input_source のプロパティ: input_mode_id, input_source_id, language (ただしIMEオフのプレーンな状態=keylayout.ABCの場合はinput_source_id, languageの二つだけ)を, 全て指定して入力ソースを変更するようにしたところ, この現象は治まった.

(3) KEの select_input_source と UnicodeHexInput の動作不安定

仕様制限で解決済み.

分析と考察

使い方の冒頭で述べたように, 「だくてん」, 「はんだくてん」, 「かんま」, 「ぴりおど」に
ついてはIMEの変換で出す仕様としている. これは, select_input_source とUnicodeHexInputのいずれかもしくは両方の動作が不安定なことによる.

本来は UnicodeHexInput を使って出したかったが, KEの to 項に一連のUnicodeの16進数入力シーケンスを記述すると, 30％程度の確率で文字化けが入力されてしまうことがわかった. ディレイ時間を記述するなどしてテストしたが, あまり状況は変わらなかった.

このためselect_input_source を使って UnicodeHexInput で所望の文字を送出する方式は断念し, IMEのローマ字入力からの変換して出す仕様とした.

end.

​