痴漢が襲いと変換しようとした賢さ。
ともかく、一切作業に取りかかっていないが、やるしかないことなので先に書いとく。
真魚で一括の置換をやらせると、遅くて待たされるので改善する予定。

なぜ遅いかという話を書いておく。
検索は高速である。なにせテキストの保持仕方が単純なので、
普通にBM法が通っちゃって、これ以上ないって位高速だろうさ。
検索でヒットしたらその単語を選択する。
すると、入力位置が動くので、必要ならスクロールが発生する。
ここまでは、検索でも置換でも同じ。
で、置換の場合は、確認ダイアログが出現する。
ここでようやく選択語句を、新たな単語に置き換えるわけだが、
旧単語を消してその分詰めて、新単語文字数分空けて、新単語を入れて、
その際、アンドゥやらその他の保持すべき情報を更新し、
折り返しのチェックをして、色分けの準備を行単位で行い、
さらに描画の必要があれば本格的な色分け処理を行い、やっと画面表示する。
連続の置換では毎回毎回描画を求めてはいないが、
それ以外のメモリーの細かい移動作業と色分けのチェックはボトルネックだ。

いや、遅いと言っても、一発ずつの置換は一瞬なので問題ないわけで、
一気にゴッソリ置換する場合がイライラするわけだ。
どうして一気にゴッソリ置換する事があるのかというと、
先日やった、文字コード変換テーブルの、DelphiからC#への移植だ。
16進数の数字自体は変ってないが、Delphiでは＄、C#では0xなわけだから、
単純な置換をテキストエディタでも出来るわけだけど、
一つ変換するたびに増えたり減ったりしてメモリーのコピーをし、
そのたびに行ごとに折り返しと色分けのチェックしてるわけで、
一括で全部置換して、終わってから全てチェックするようにしなきゃいかん。
いかんのは初めからわかっててさぼってきて、いざ自分で使って必要になった。

Undoも一括で置換させた部分は一括で戻し、一つ一つやった部分は一つずつ戻す。
これが正しい動作だし、余計な事しない分高速だって事は十分わかってる。
単に、置換を大量にやる機会が少ないがために、優先順位が低迷しただけだ。
でもこれはやらなきゃいかん。

やる前から書いておかないとまたやらないので書くだけ書かなきゃ。