## 経緯 現状、[[Predictable complement]]は近しい1つの候補しか補完できない。たとえば ``` dog doc ▼ d ``` というファイルがあったとき (▼はカーソル)、[[Predictable complement]]を実行すると `doc` しか補完されない。だが実際は、実行するたびに `doc` -> `dog` -> `doc` みたくサイクルしてほしい。 [[Current file complement]]でいいじゃないかという話もあるが、[[Predictable complement]]のメリットは **確信的かつ確定的** な補完ができることにある。候補が表示されるのを確認している時点で、時すでに遅しなのだ。 ## やること [[Predictable complement]]を実行したときの解析ロジックを変更し ```diff - 直近のマッチする単語を1つ取得 + 範囲内のマッチする単語を、近い順にリストで取得 ``` としたうえで『実行するたびに1つあとのindex候補を出力する』ようにする。 ## 懸念点 この実装にはいくつかの技術的な懸念点がある。 - [[Predictable complement]]の継続中であることをどう判断するか? - 入力済のテキストをうまく置換できるのか? これについては状態を持つ必要があるだろう。 - 現在の補完リスト: `string[]` - 現在の選択index: `number | undefined` - `undefined`でなければ継続中 現在の選択indexが切り替わるのは、カーソルやファイルが移動したタイミング。このタイミングで`undefined`に切り替える。 直前の候補を削除する方法は、挿入した文字列の長さを記録しておき、その数だけ削除して挿入しなおせばよい。正確には、『現在のカーソルから、x軸に直前の挿入文字列の長さだけ戻った場所のrangeに対してリプレイス』する。 これらの状態をどこで管理するのかは検討が必要。 ## TODO - [ ] [[Predictable complement]]の処理はAutoCompleteSuggestにいらない気がする - [ ] 専用のファイルやclassを用意した方がいい - [ ] appの初期化時に上記を初期化し、状態管理とコマンド実行時に関数を実行する - [ ] カーソルやファイル移動イベントを判定する方法の調査 - [ ] 状態を保持する場所の調査 - [ ] 補完リストの保持 - [ ] 現在の選択indexの保持 - [ ] 挿入切り替え実装