## ユースケース - 編集中のNoteによって利用する補完候補のパターンは変わる - 例 - 議事録をとっているときは、同じ人の名前を多用する - ゲームのNoteをとっているときは、そのゲームに登場する用語を多用する - とはいえNoteごとに補完傾向を保存するのはダメ - 大抵のNoteは作成時に一気に書くだけであり、編集の頻度はそこまで高くないから - ==執筆中の傾向を読み取って補完に反映させた方がいい== - Noteが切り替わったら傾向をリセットするのはダメ - ちょっとファイル移動したら補完傾向が切り替わるのはマズイ - **別のNoteを見ながら編集することができなくなる** - 候補には出にくいが、全体を通してよく使う候補がある - 好きな単語とか - よく使うCustom dictionaryとか - 例 - よく使う[[コールアウト]]を補完したい場合 - Custom dictionaryならそういう風に言語調整はできる - が.. 明示的にそれをやるのは面倒なので、暗黙的にイイ感じにやってほしい - デメリット - [[内部リンク]]が一番上に上がってこない可能性 - 現状は[[内部リンク]]があればそれが最優先されるようになっている - [[内部リンク]]以外のワードを選択してしまうと、意識せずに[[内部リンク]]を挿入する作業がやりにくくなるかも - [[内部リンク]]を挿入する場合は ==打ち込むワードは決まっているが、それが[[内部リンク]]に存在するかあいまいなケース== - なので、最後まで打ち込んでから候補を確認するケースが多い気がする - 例 - [[Python]]なら`python`と入力してから、候補に存在すれば補完する - `py`の時点で候補に出てくることはそこまで期待していない - 編集中Noteで頻出するモノなら出てきた方が嬉しいかもだけど - なのでノイズはそこまで神経質にならなくていいかもしれない - [[📜Various Complementsのリリースを自動化する]] を選択したら、`va`でそれが一番上に出てくるのは本当にいいのか..?? - 選択回数だけでなく、==どのクエリに対して補完したか== も重要な気がする - もし`va`の入力からそれが選ばれたなら、`va`がそれを連想させる強い意志があるということ - なので上に上げていい気がする - 一方、`Various Complements`まで入力して初めて選ばれたなら、`va`の時点で出すべきではない - `Various Complements` かその付近で出すのが自然 - `suggestion.length` - `query.length` - この数が大きいほど、queryに対する意思が強いということ - つまり候補の上位に出した方がいい - `a.value.length`と`b.value.length`の差と、`suggestion.length` - `query.length` を考慮して出せばいいのでは..? ## 要素 - サジェストの長さ - クエリの長さ - 最後に選択した日時 - 選択回数 ## 計算式その1 ### 補完距離 (completionDistance) 候補の`suggestion.length` - `query.length` + 1 例: サジェストA, Bがあったとする。 | サジェスト | value | length | | ---------- | ---------------------------- | ------ | | A | [[🦉Another Quick Switcher]] | 23 | | B | another | 7 | - `ano`と入力たら、[[🦉Another Quick Switcher]]の補完距離は20 - `ano`と入力たら、anotherの補完距離は4 - `another`と入力したら、anotherの補完距離は0 ### 累積補完距離 (accumulatedCompletionDistance) 補完距離の累積。 - 加算のタイミングは候補が選択されたとき - `補完距離+1` を加算 - 加算の対象は補完の対象 (**aliasと値は区別する**) > [!hint]- +1の理由 > +1をしないと完全一致の補完決定は0になる。ただ、0ではそれが優遇されることはない。選択された事実は考慮したいので完全一致でもプラスになるよう調整している。特に[[内部リンク]]の場合 ### 選択時の優先度ロジック `ano`と入力したとき以下の候補が表示される。 | サジェスト | value | length | 補完距離 | | ---------- | ---------------------------- | ------ | -------- | | A | ano | 3 | 0 | | B | anoth | 5 | 0 | | C | another | 7 | 4 | | D | anonymous | 9 | 8 | | E | [[🦉Another Quick Switcher]] | 23 | 20 | - 候補Cは過去に`ano`で1回補完されたことがある - 候補Dは過去に`anony`で2回補完されたことがある - 候補Eは過去に`ano`で1回補完されたことがある これを `suggestion.length` - 補完距離として見ると以下の優先順位になる。 | サジェスト | value | length - 補完距離 | | ---------- | ---------------------------- | ------ | | D | anonymous | 1 | | A | ano | 3 | | C | another | 3 | | E | [[🦉Another Quick Switcher]] | 3 | | B | anoth | 5 | このあと、`another quick`で[[🦉Another Quick Switcher]]が補完された場合は、補完距離が+9されるため以下の順になる。 | サジェスト | value | length - 補完距離 | | ---------- | ---------------------------- | ----------------- | | E | [[🦉Another Quick Switcher]] | -3 | | D | anonymous | 1 | | A | ano | 3 | | C | another | 3 | | B | anoth | 5 | > [!todo] > さらに最終更新日時も考慮できるとbetter ## 計算式その2 補完距離は良さそうに見えるが以下の欠点がある。 - ほぼ入力して補完したものが次にすぐ補完した場合、字数の短い候補にしばらく負けてしまう - 短めの補完をよく使う場合でも、長い補完を一度選んでしまうとしばらく逆転できない 良さそうに見えたけどデメリットの方が多そうなので、補完距離ナシで考えてみる。 ### カウント (count) - 選択されたカウント - 選択されたら+1 ### スコア (score) カウントと最終選択日時から算出する。計算式は以下。 ``` count * 最終選択日時ボーナス ``` `最終選択日ボーナス`は以下。 | 最終選択日時が | スコアボーナス | | -------------- | -------------- | | 1時間以内 | 4倍 | | 1日以内 | 2倍 | | 1週間以内 | 0.5倍 | | それ以外 | 0.25倍 |