Closed kachick closed 10 months ago
どういうタイポするんですか
いい質問ですね! それを書いておけば原因も追求しやすいだろうと思ってました。
typoの言語化か… あまり好きじゃないしな。 しかし案外、いや、やはりというべきか。 自分をつかむカギはそこにあるか…
今ばっと無心で書き出してみたらこのようなスペルが生成されましたのでご笑納ください。
minimumn maximumn
末尾に n が多いだけだと、芸術点がやや低めに出てしまうかもしれませんね...! とはいえどのように誤るかを知っていれば、対策も見えてくるかもしれない
"\n" をつけてるような物だと考えれば、むしろ正しいのでは・・・
ブラウザの履歴補完からここに飛べるので、一旦Google検索かけるよりちょっとマシになった!
redundant も redandunt にしてまう
receive を recieve にしちゃったりはないんですか
あー、それは昔鍛えて直した気がする(書く度に毎回頭の中で「レセイブ」と声を出している)
しかし怪しいなと思ってコード検索してみたら、10年以上前のコードとかには結構あった・・・ https://github.com/search?q=recieve+user%3Akachick&type=code
いや、今でも typo check がなければ recieve と書いてそうだな と思ってぐぐったら、1/3ぐらいこっちじゃん。もはやよくある typo とかいうレベル超えてるのでは・・・
しかも多すぎてグーグルさんがもしかしてと言わない
役不足とか確信犯みたいに、誤用のほうが勝つパターンかもしれないからね。時がくるのを待とう
ジェネレーティブAIに、typo混じりのそれっぽい文章を大量に生成させて放流すれば覇権取れるのではないか。 勝てば官軍だからね
どんどん typos へ突っ込むためにも、どんどん新しい間違いしないと https://github.com/pankona/pankona.github.com/pull/169#issuecomment-1660967200
自分の能力限界だと諦めて、ツールで支えてもらうようにした https://github.com/kachick/dotfiles/pull/325
尚 githooks の話でよく当たる、 global と local ガッツンコ問題を解消するためにごちゃごちゃ書くのやだったのでなんも対処してない conventional commits が基本好きではなくて使ってない https://github.com/kachick/times_kachick/issues/28 から当面あんま困らないという事情がある・・・。もし必要ならそのリポジトリ側の local hooks で上書きされるんだろうし、それはそれで仕方ないと割り切っとく
💭 この方法だと、 commit message 内に s/typo/correct/
みたいに書いて typo 修正コミット積んでも死ぬなー。でもまぁ、その時はわかった上で --no-verify で commit し直せばいいだけか・・・
このコミットフックによる typo check で1日3回ぐらい助けられてる。commit メッセージの typo はある意味コンテンツより直しにくいというか手が出せないとこだったので、結構嬉しい。 もっと早くやっておけばよかった(昔 secret の漏洩チェックみたいな hooks を職場で強要された時にめちゃくちゃ重くなってから hooks に関してグローバルで有効にするのネガティブだった)
https://github.com/crate-ci/typos/releases/tag/v1.20.0 で AIベースの他ツールからリストをインポートしたようで、誤検知が大量に増えてた。 IMEとかJSTに自分は引っかかったんで非英語圏だけ問題になるんかなと思ったら、EOF(修正済み)とかGUIDも引っかかるようになってて割と厳しかった。 辞書を更新さえすれば後は自動生成といううまい作りになっているようでわからないなりにPRを幾つか出してみたんだけど、そもそもbaがハッシュ値に引っかるみたいな話とか含めて記憶に残ってる限り大半の御検知は2~3文字のやたら短い語句で発生しているので、これはもうトレードオフの問題だなと3文字以下の検知は全て切り捨てるようにしてみた。
やっぱ短い単語でもtypoるわー。となるのかどうか個人的に様子見する
https://github.com/kachick/dotfiles/pull/538 https://github.com/kachick/anylang-template/commit/08daf44b5dc4c1f59390feabbf2600eefae8a5fd
注意するところは ignore にまつわる config がファイルを対象にするものと単語を対象にするもの。更に単語の中でも(多分) 修正元、修正先、検知対象文字列 とかに分かれてるっぽいのでコードをあんま読めないから挙動確認しながらやってた。 今回みたいな用途だと多分 extend-ignore-words-re が向いてそう
別にスペルの話じゃないながらhttps://scrapbox.io/nishio/%E6%84%8F%E5%91%B3%E3%81%AE%E8%BF%91%E3%81%95%E3%81%AE%E8%A7%A3%E9%87%88%E6%8F%BA%E3%82%8C を読んでてちょっと思ったのが、最近の spell checker ってどれもこれも正しいリスト登録してそこから外れるかどうかとレーベンシュタイン距離の近さで誤字疑いや候補を検出してたと思うんだけど、結局それだと誤検出(false positive)が多くなるからチマチマ除外リストへ追加しないといけないのが一番ネックだった。特に人名とか固有名詞で都度引っかかるのは辛い そこにこの typos は(別に全部コード読めてないから多分大体想像でだけど) 徹底した経験則とか集合知で殴ることで誤検出をめっちゃ低減させてたのが他と大差なアドバンテージだった。 距離は近くてもそうは中々間違えんだろみたいなの、キーボードの配列と人間の身体の作りとかからもあると思うんよね
そこに他のツールでやってた、恐らく多分に機械的に生成されたであろうリストがインジェクトされたことで、全体から見ると僅かな量でも誤検出が爆増したのはまぁそうよなという感じがある(ただ実際増えた中のtypoで自分が最近しているものも一個だけあったので、良い方にも目を向けたい気はする。メンテナがrevertしてないのもそういうことだと思う)
リストベースなので、 2 hop というか 2箇所ミスってるとさすがに相手にしてられんわという感じでチェックから漏れやすい
together の h 抜けの togeter、e と a 間違えの togather、 は検知出来るけれど両方を備えた togater みたいなのはだめみたいな まーとりあえず気づく都度 code 検索と google検索ざっと掛けた後でリクエストするようにはしている・・・
課題
How