症状
実端末で tecode を起動してファイルを開いても、文字入力が一切効かない。一方で ctrl+g(コマンドパレット)は正常に動作する。
根本原因
editor/inputRouter.ts の routeKeyEvent は先頭で入力を editorTextFocus でゲートしている(Req 4.6)。
if(!context.get("editorTextFocus"))returnfalse;そして起動時にエディタのテキスト面をフォーカスする処理がどこにも存在しない。.focus() の命令的な呼び出しは ui/shell.tsx の EditorArea に 1 箇所あるだけで、それは「検索ウィジェットが閉じた」エッジ遷移専用(find.isOpen の true→false)。初回マウント時には走らない。
結果として editorTextFocus は undefined のまま残り、印字可能文字は routeKeyEvent に入った瞬間に捨てられる。workbench.action.showCommands のように when 句を持たないバインド済みコマンドはキーマップ経由で解決されるためゲートを通らず、正常に動く。報告された症状と完全に一致する。
再現
本番と同じ経路(focusEditorText の補助なし)で Shell をマウントした結果。
editorTextFocus after mount = undefined
editorFocus after mount = undefined
text before = "hello\n"
text after = "hello\n" ← "X" を送っても変化なし
INSERTED? false
なぜテストで検出できなかったか
入力を行うテストは editingScenario.e2e.test.tsx と typingBenchmark.test.ts の 2 つだけで、どちらも入力前に editingHarness.tsx の focusEditorText() を明示的に呼んでいる。このヘルパーはフォーカス可能ノードを走査して editorTextFocus が true になるまで .focus() を試すもので、本番には存在しない動作。
focusEditorText はショートカット(context.set("editorTextFocus", true))を避けて実 focus() を使う点で正しく書かれているが、「誰がフォーカスを与えるのか」という一段前の問いを肩代わりしてしまっている。そのため本番起動経路を通るテストが 1 つも存在しない状態だった。
修正方針
アクティブなドキュメントが存在するとき、テキスト面が初めて利用可能になった時点でフォーカスする。EditorArea は既に onTextPlaneNode 経由で textPlaneNodeRef を保持しているので、その仕組みを再利用できる。
ただしフォーカスを奪ってはいけない相手がある:コマンドパレット / クイックピック / 入力ボックス / 検索ウィジェットが開いている間は、そちらが正当にフォーカスを持つ。初期フォーカスはそれらが非アクティブなときに限る必要がある。
併せて確認したい別症状
終了後に、打鍵した文字がシェルの標準出力に現れることがあるとの報告。こちらは未確定。本件の副作用(tecode がキーを消費せず捨てているため)である可能性が高く、本修正で解消するかを確認したい。なお ctrl+q は実際には未バインドで、終了は ctrl+c(シグナル経由でターミナル復元が走る経路)と思われるため、終了処理側の問題である可能性は相対的に低いと見ている。
回帰防止
本番の起動経路(focusEditorText を呼ばない)でマウントし、印字文字がドキュメントに挿入されることを検証するテストが必要。既存の入力系テストがすべてフォーカス補助に依存している以上、これがないと同じ穴がまた開く。
症状
実端末で tecode を起動してファイルを開いても、文字入力が一切効かない。一方で
ctrl+g(コマンドパレット)は正常に動作する。根本原因
editor/inputRouter.tsのrouteKeyEventは先頭で入力をeditorTextFocusでゲートしている(Req 4.6)。そして起動時にエディタのテキスト面をフォーカスする処理がどこにも存在しない。
.focus()の命令的な呼び出しはui/shell.tsxのEditorAreaに 1 箇所あるだけで、それは「検索ウィジェットが閉じた」エッジ遷移専用(find.isOpenの true→false)。初回マウント時には走らない。結果として
editorTextFocusはundefinedのまま残り、印字可能文字はrouteKeyEventに入った瞬間に捨てられる。workbench.action.showCommandsのようにwhen句を持たないバインド済みコマンドはキーマップ経由で解決されるためゲートを通らず、正常に動く。報告された症状と完全に一致する。再現
本番と同じ経路(
focusEditorTextの補助なし)で Shell をマウントした結果。なぜテストで検出できなかったか
入力を行うテストは
editingScenario.e2e.test.tsxとtypingBenchmark.test.tsの 2 つだけで、どちらも入力前にeditingHarness.tsxのfocusEditorText()を明示的に呼んでいる。このヘルパーはフォーカス可能ノードを走査してeditorTextFocusが true になるまで.focus()を試すもので、本番には存在しない動作。focusEditorTextはショートカット(context.set("editorTextFocus", true))を避けて実focus()を使う点で正しく書かれているが、「誰がフォーカスを与えるのか」という一段前の問いを肩代わりしてしまっている。そのため本番起動経路を通るテストが 1 つも存在しない状態だった。修正方針
アクティブなドキュメントが存在するとき、テキスト面が初めて利用可能になった時点でフォーカスする。
EditorAreaは既にonTextPlaneNode経由でtextPlaneNodeRefを保持しているので、その仕組みを再利用できる。ただしフォーカスを奪ってはいけない相手がある:コマンドパレット / クイックピック / 入力ボックス / 検索ウィジェットが開いている間は、そちらが正当にフォーカスを持つ。初期フォーカスはそれらが非アクティブなときに限る必要がある。
併せて確認したい別症状
終了後に、打鍵した文字がシェルの標準出力に現れることがあるとの報告。こちらは未確定。本件の副作用(tecode がキーを消費せず捨てているため)である可能性が高く、本修正で解消するかを確認したい。なお
ctrl+qは実際には未バインドで、終了はctrl+c(シグナル経由でターミナル復元が走る経路)と思われるため、終了処理側の問題である可能性は相対的に低いと見ている。回帰防止
本番の起動経路(
focusEditorTextを呼ばない)でマウントし、印字文字がドキュメントに挿入されることを検証するテストが必要。既存の入力系テストがすべてフォーカス補助に依存している以上、これがないと同じ穴がまた開く。