textlint-rule-no-doubled-joshi

textlint-rule-no-doubled-joshi copied to clipboard

〜でも〜でも

2

> AでもBでも > AしたりBしたり は例示・並列・対表現としてあるため、デフォルトで除外しても良さそう。 ちょっと文章によって冗長な感じがするので、オプションで禁止にはできていい気がする。 - [textlint-ja/textlint-rule-prefer-tari-tari: 例示・並列・対表現の「〜たり〜たりする」をチェックするtextlintルール](https://github.com/textlint-ja/textlint-rule-prefer-tari-tari)

azu

"に"の連続

8

> `pre`/`post` scriptを自動的に実行しないように はvalidな気がする

azu

がの連続

3

> リリース中にproductionビルドだとアプリが動作しないバグが見つかる とか `が` がかかってもおかしくないケースな気がする

azu

#2 #3 で"、"をデフォルトでは許容するように変更した。 この変更により、本来はエラーとしていたものも許容されるケースがある。 `strict: true`の場合は本来のエラーを再現した挙動を維持した状態となっている。 "、"がコンテキストにより意味合いが変わるため、それを補足する方法について考えるIssue > ものすごく安直な実装だと、を間隔値(+1)することで > > ``` > 「右がiPhone、左がAndroidです。」 > ``` > > "が" と "が" で間隔値は2になるのでパスできます。(デフォルトでは間隔値2以上はセーフとゆるめ) > > ``` > 36a0498 という感じで > >...

azu

文の途中に改行があるとエラーになる

2

以下の文で no-doubled-joshi のエラーが発生しました。 ```text 関数でアクセスで きる。 ``` 以下のコマンドを bash 上で実行すると再現します。 ``` $ npm init -y $ npm install textlint textlint-rule-no-doubled-joshi --save-dev $ echo -e "関数でアクセスで\nきる。" > test.txt $ npx textlint...

tanioka256

https://www.promptfoo.dev/ を使いtextlintルールのエラーメッセージをLLMで評価し、そのエラーメッセージが妥当かを判断したい # エラーメッセージの評価基準 ## 1. 明確性 (clarity) - ユーザーが何が問題なのかを理解できるか - 専門用語が適切に説明されているか - メッセージの構造が分かりやすいか ## 2. 正確性 (accuracy) - 技術的に正しい指摘か - 指摘された問題が実際に存在するか - 誤検知ではないか ## 3. 修正可能性 (fixability) - 具体的な修正方法が示されているか...

azu