脳log[20150214]

2015年02月14日 (土) [SakuraEditor] [sakura-unicode:2253] これはキモい(誰のせいだ)。スペースで区切ってなくても検索語を勝手に分割してしまうのか。検索語(全体)の前後が単語境界であるかだけをテストするっていう選択肢もあったのだな(強調キーワードと同じ方式)。当時それに気づかなかったのはおそらく単語検索メソッドという道具がすでに存在していたからそれを使う何かしか見えていなかったのだろう。いずれにしろ直前の置換によって単語境界が消えた場合に一部の置換対象がスキップされたようにみえる問題は起こる。正規表現置換でも「置換の繰り返しではない[すべて置換]」以外では起こる。テキスト「あいう■■■あいう■■■あいう」検索「\b.+?\b」置換「DEF」。ただまあ、自分でパターンを入力したわけではない単語検索では GREP置換と同じ結果がわかりやすいと思う。■■■どうやって実現するかは知らない。(個人ビルドの)色分けを SHJS方式にして行単位で色分けの状態を保存し行単位で色分けを行うと決めたときに思い知ったけど、それは改行文字が極端に少ないテキストで速度が低下するってことだ。折り返さない設定でも実は数万桁で折り返しているというのは最悪時のパフォーマンスを入力(テキストエディタの入力はテキスト)によらず予測可能な範囲にとどめる処置だ。というわけで改修するとしてもインクリメンタルな処理は維持したくて、検索置換イテレーションの一部をオーバーラップさせて置換するまえに次の検索を行うとかが考えられるけど、マッチ位置を検索語・置換文字の文字数差(バイト数差)で前後移動させるのが危なっかしいというか、改行文字が消えたり現れたり折り返し位置をまたぐ置換の時にどうなるのという不安がある。サクラエディタ固有の問題として置換対象の指定がたぶんビューと範囲選択(レイアウト単位)を経由した迂遠な方法になっているだろうからバイト単位でマッチ位置を移動させることができない場合があるのではないかとかいう不安もある。とかとか考えてると MS伝家の宝刀"by design"も悪くない気がする不思議。■■■@2015-03-07 JavaScriptで "A\nA\nA\nZ".replace(/^A\n/gm, "B") の値は "BBBZ"。これは Grep置換と同じ。文字列が immutableな(実装はどうあれそう振る舞う) JavaScriptからヒントをもらったもう一案。行バッファをもうひとつ用意してマッチ部分(の置換済み文字列)と非マッチ部分を交互に新バッファにコピーしていく。でも「Expand(20100907p01.01)」がないんよね。検索と同時に置換してしまうと何の解決にもならないし。