## 概要
### 全体条件
- strategyは`japanese`
- [[Current file complement]] 有効
- [[Custom dictionary complement]] 無効
### 再現手順
[[ノート]]に以下を書く。
```markdown
123
456
```
同一[[ノート]]のどこかで`123`と入力すると`123456`が補完候補に出現する。
- `123`や`456`単体の候補は出現しない
- strategyが`default`では発生しない
## 原因調査
`tokens` の時点で既に問題の候補が存在している。
```ts
const tokens = this.tokenizer
.tokenize(content)
.filter((x) => {
if (x.length < option.minNumberOfCharacters) {
return false;
}
if (this.tokenizer.shouldIgnoreOnCurrent(x)) {
return false;
}
return option.onlyEnglish ? allAlphabets(x) : true;
})
.map((x) => (startsSmallLetterOnlyFirst(x) ? x.toLowerCase() : x));
console.log(tokens);
```
tokenizeの戻り値で既に再現している。
```ts
export class JapaneseTokenizer implements Tokenizer {
tokenize(content: string, raw?: boolean): string[] {
return pickTokensAsJapanese(content, raw ? / /g : this.getTrimPattern());
}
```
```ts
function pickTokensAsJapanese(content: string, trimPattern: RegExp): string[] {
return joinNumberWithSymbol(
content
.split(trimPattern)
.filter((x) => x !== "")
.flatMap<string>((x) => segmenter.segment(x))
);
}
```
`joinNumberWithSymbol`前の状況を確認してみた。
```
63 : "1"
64 : "2"
65 : "3"
66 : "4"
67 : "5"
68 : "6"
```
ああ... 改行区切りが考慮されていないから、65と66の境目が分からずにこうなってしまうのか...。
defaultの場合はtokenizeの内部で`\n`を含むパターンのsplitをしているから問題なさそう。
```ts
export const TRIM_CHAR_PATTERN = /[\n\t\[\]$/:?!=()<>"',|;*~ `_“„«»‹›‚‘’”]/g;
export class DefaultTokenizer implements Tokenizer {
tokenize(content: string, raw?: boolean): string[] {
const tokens = raw
? Array.from(splitRaw(content, this.getTrimPattern())).filter(
(x) => x !== " "
)
: pickTokens(content, this.getTrimPattern());
return tokens.map((x) => x.replace(/\.+$/g, ""));
}
```
ただjapaneseもちゃんとやってる。というよりも改行で区切るから境目が分からなくて困る?
```ts
function pickTokensAsJapanese(content: string, trimPattern: RegExp): string[] {
return joinNumberWithSymbol(
content
.split(trimPattern)
.filter((x) => x !== "")
.flatMap<string>((x) => segmenter.segment(x))
);
}
```
```
aaa
bbb
111
222
- 123
2023-05-25
```
↓
```
[aaa, bbb, 111, 222, -, 123, 2023-05-25]
[aaa, bbb, [1, 1, 1], [2, 2, 2], -, [1, 2, 3], [2, 0, .... , 5]]
[aaa, bbb, 1, 1, 1, 2, 2, 2, -, 1, 2, 3, 2, 0, .. , 5]
[aaa, bbb, 111222-123202305-25]
```
flatMapしてからjoinがまずい気がする。
```
[aaa, bbb, [1, 1, 1], [2, 2, 2], -, [1, 2, 3], [2, 0, .... , 5]]
[aaa, bbb, 1, 1, 1, 2, 2, 2, -, 1, 2, 3, 2, 0, .. , 5]
[aaa, bbb, 111222-123202305-25]
```
こうじゃなくて、こう
```
[aaa, bbb, [1, 1, 1], [2, 2, 2], -, [1, 2, 3], [2, 0, .... , 5]]
[aaa, bbb, [111], [222], -, [123], [2023-05-25]]
[aaa, bbb, 111, 222, -, 123, 2023-05-25]
```
なので `map(joinNumberWithSymbol)` してから `flatten` かなと。`flatMap(joinNumberWithSymbol)`でいいか。
## TODO
- [x] 原因調査
- [x] `123456`の存在
- [x] `-123`の存在
- [x] 数字が繋がってしまう問題
- [x] 仮テストを書く
- [x] 仮実装を書く
- [x] リファクタリング
- [x] ハイフンと数字が繋がってしまう問題
- [x] 仮テストを書く
- [x] 仮実装を書く
- [x] リファクタリング
- [x] パフォーマンス
- 理論的には走査のリスト数が増えるから少しおそくなる気はする
- ただ、走査の要素数はほぼ変わらないと思うのでクリティカルにはならないはず
- [x] beforeパフォーマンス
- 21msちょい -> 7ms -> 5ms
- 5-6msくらい
- [x] afterパフォーマンス
- 12ms -> 9ms -> 5ms
- 5-7msくらい
- [x] パフォーマンスの結論
- 問題ない
- beforeの21msはたまたまで、どちらも5ms前後というのが信頼できる情報