ewdernaandClaude Opus 5.5
1c99f60719
- 役割はホスト(OS×ホスト配列)がキーコードをどう解釈するかの記述。IMEの変換はOSの責務で対象外 - データはキーボードに依存しないプロファイルの共有カタログ。識別はOS×ホスト配列(+入力方式) - プロファイルは順方向の表・成立の前提・対応可否(3値)だけを持つ。逆引きと実現可否の判断は使う側(P-1で要確認) - MAPはキーコードを保存し、逆引きは一方向の入力補助とする - 複数ホストの扱いをP-2とし、MAP-P-5の参照をHSTへ向ける Journal: journal/2026-09-24-hst-layer-scope.md Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017W6AsoJYTiN3bnxvSMS87f
3.6 KiB
3.6 KiB
IMEレイヤーの再定義(HST)と線引き
結論
- IMEレイヤーをHST(ホスト)レイヤーに改める。役割は、ホストがキーコードをどう解釈するかの記述。IMEの変換はOSの仕事で対象外。
- データは、ホスト環境ごとのプロファイルを集めた共有カタログ。キーボードに依存しない。プロジェクトはプロファイルのIDと差分だけを持つ。
- 識別はOS×ホスト配列(+必要なら入力方式)。
win-jpなどはプリセット名。 - プロファイルは順方向の表 f(キーコード, 修飾キー, ホスト状態) → 文字/動作/未定義/不明、成立の前提、対応可否(3値)だけを持つ。
- 逆引き・候補の生成・ファームウェアでの実現はMAPエディタとGeneratorが行う。ユーザーは、これが実現できるかに不安がある → HSTのP-1。
- MAPはキーコードを保存する。逆引きは入力補助で、一方向の変換。
- 複数ホストの扱いは未決 → HSTのP-2。
案の比較
| 論点 | 当初の提案(人との議論) | Claude | Codex | 採用 |
|---|---|---|---|---|
| 名前 | SYS | HOST/HST | SYS → 最終的にHOST/HSTに同意 | HST |
| 識別子 | WIN-JAP (OS×言語) | OS×配列の構造 | OS×配列×入力方式+プロファイル名 | OS×配列(+入力方式) |
| 範囲 | OS・言語ごとのキーの振る舞い・表示 | ホストの解釈の記述 | 意図を環境ごとの出力に変換、まで候補 → 最終的に「対応関係を提供、変更はしない」 | 記述のみ |
| 逆引き | - | 使う側で順方向の表から求める | 候補と成立条件をプロファイルが持つ | 使う側 |
| ホスト状態 | - | 関数の引数として記述 | 設定と実行時の状態を分ける | 両方(矛盾しない) |
根拠・経緯
- SYSは、HIDのSystem Control用途ページ(電源・スリープ)や「システム設定全般」と紛らわしい。hostはHIDでキーボードの接続相手を指す用語で、QMKも「host keyboard layout」と呼ぶ。
- 言語は軸として誤り: 日本語Windowsで英語配列を使える。MacではUS/JISが入力ソースとキーボード種別で決まる。XKBはlayout/variant/optionsの3要素。
「英語」にもUS・UKがある。
JAPはISOコードでもない(ja/jpn)。 - 逆引きをプロファイルに持たせない理由: (1) 順方向の表から導けるので二重管理になる。 (2) 候補がファームウェアの機能に依存する。例: US刻印+JISホストでShiftの組が合わないキーにはKey Overrideが要る。HSTにQMKの知識が混ざる。
- Codexの指摘で採用したもの: 表示の切り替えと送信内容の変更を混ぜない。知らない動作を「使えない」と扱わない(対応可否を3値にする)。OS設定への依存は記述する。
- MAPの正本をキーコードにする理由の修正: Claudeは当初「VIAでは実機にキーコードしか残らず、意図を復元できないので、キーコードでなければならない」とした。 Codexが、意図をプロジェクト側に残す設計も可能で、難しくなるのは実機で変更された値の取り込みだけだと反論し、これが正しい。 採用する理由は「実機との往復を単純に保てるから」とする。
- 「コピー」のような操作の辞書は、アプリやユーザー設定まで相手が広がるので対象外。
- 未採用のアイデア: キートップの刻印生成にHSTを使う(PHYのラベルへ流す)。検討していないので仕様には書かない。