タグ付き検索の仕様 - 秀丸エディタβ版 - スレッド04534, 2009/11/22

タグ付き検索の仕様

カモノハシ さん　09/11/22 20:46

こんばんは、いつもお世話になっております。カモノハシです。
HmJre.dllのタグ付き検索についてです。

「aaabbb\n\n」という文字列に対する検索です。

パターン1　「(?\1)(aaabbb)(\n)(\n)」
パターン2　「(?\2)(aaabbb)(\n)(\n)」
パターン3　「(?\3)(aaabbb)(\n)(\n)」

では、1,2は成功し目的の文字列のみがマッチしますが、3は検索そのものが失敗し
ます。
複数行検索の制限にかかっているのか、たんなるバグか、判断がつきかねましたの
で、お聞きする次第です。
よろしくお願いし致します。

環境：WindowsXPSP3+v8.00b26 32bit + HmJre.dll 2.06

RE:04534 タグ付き検索の仕様

h-tom さん　09/11/23 00:53

h-tom です。

>では、1,2は成功し目的の文字列のみがマッチしますが、3は検索そのものが失敗し
>ます。
>複数行検索の制限にかかっているのか、たんなるバグか、判断がつきかねましたの
>で、お聞きする次第です。
>よろしくお願いし致します。
おそらく、仕様だと思います。
　turukame.3:02419| 複数行の検索で (?\\1) が使えない
を、参照。

RE:04535 タグ付き検索の仕様

カモノハシ さん　09/11/23 23:09

こんばんは、いつもお世話になっております。カモノハシです。
> おそらく、仕様だと思います。
> 　turukame.3:02419| 複数行の検索で (?\\1) が使えない
> を、参照。
レスありがとうございます。
仕様だったんですか。
ざっと参照先を見たんですが、複雑で理解が及ばなかったです。
もうすこし考えてみます。

RE:04536 タグ付き検索の仕様

カモノハシ さん　09/11/26 19:27

こんばんは、いつもお世話になっております。カモノハシです。

参照先
turukame.3:02419
turukame.1:01373
を読んでみました。
2種類の提案をさせて下さい。

案1　複数行検索の充実
案2　(?\tag-number)形式の2行目以降のマッチに最適化

# まだまだ煮詰められていない案ですので、実現不能かもしれません。
# ベータテストが終盤なのに、提案を強行して申し訳ありません。

[案1]複数行検索の充実
要点：
　正規表現での検索を、基本一行ずつ渡し、検索に次の行の情報が必要ならば、コ
　ールバック関数を通じて提供する。

前提：
　正規表現のアルゴリズム及び実際のHmJre.dllの実装がどうなっているのか、理解
　に乏しいため、実現可能性がどの程度あるのかは分かりません。

詳細：
　検索時は、カーソル行のデータを変換し改行を付与してDLLへ渡す。
　このとき、次行以降のデータを渡すためのコールバック関数も渡す。
　DLLは、渡されたデータを検索する。
　このとき、マッチ範囲が末尾で終わる/後方不一致/後方一致の事由、又は、その
　行にマッチしうる文字列が存在しないこと、により、改行コードより先、つまり
　次行のデータが必要になれば、コールバック関数により、データを取得して、検
　索を続行する。
　コールバック関数は要求された次行のデータを変換して引き渡す。
　(なお、このとき、フラグを用いれば、検索の中断も可能。)

問題点：
　後方検索ではなく、前方検索の場合に適用できるのか不明。
　正規表現の実装に明るくないため、どの程度バックトラック等により、マッチン
　グ処理をしている地点より前の文字列が必要になるのか不明。
　これが長大になる可能性が高いならば、さらなる検討を要する。
　改変にどの程度工数を要するのか不明。

副次的利点：
　\n+のような正規表現がユーザフレンドリーにマッチする。
　マッチする候補がカーソル行以外にあるときの、検索速度が上がる。

[案2](?\tag-number)形式の2行目以降のマッチに最適化
要点：
　(?\tag-number)形式が与えられたら、秀丸側で、いったんこれを削除し、マッチ
　した文字列に対し、再度オリジナルのパターンで検索する。

詳細：
　検索時に、(?\tag-number)形式のパターンが与えられたら、これを削除したパタ
　ーンで検索をする。
　マッチした範囲を改めて、指定し、オリジナルのパターンで検索する。
　(改変パターンでマッチした時に渡したデータと同一データを渡す)
　この場合、局所的に全文を渡しての検索となるため、マッチ位置が改行コードを
　またぐか否かを気にする必要なく、マッチ位置が目的地。

問題点：
　場当たり的な対応である。
　(?\tag-number)形式での検索速度が低下する。
　パターンを二つコンパイルして保存しておく必要がある。(保存しない場合は次候
　補の検索がとてもおそくなる？)
　改変にどの程度工数を要するのか不明。

利点：
　(?\tag-number)形式にする/しないという選択で、ほぼ同一の正規表現パターンに
　よる検索の可否が分かれない。
　(「aaabbb\n\n」が成功し「(?\3)(aaabbb)(\n)(\n)」が失敗するのは直感的でな
　い)

以上です。
お忙しいなか、大変恐縮ですが、ご検討よろしくお願い致します。

RE:04592 タグ付き検索の仕様

秀丸担当 さん　09/11/27 10:29

>[案1]複数行検索の充実

まずコールバックという新たな仕組みを作るとしたら、既存の仕組みを大きく変
えなくてはいけないと思うので、利点に対してのコストが大きすぎると思われま
す。
とても長い行数が対象になる場合など、おっしゃられているような問題点のこと
も考えると現実的ではないように思います。

>[案2](?\tag-number)形式の2行目以降のマッチに最適化

HmJre.dllで２行目以降へのマッチ自体はできていて、マッチするかどうかという
点はあまり問題ではないようです。
カーソル位置からの上下移動で、相対的な移動先とヒット回数で矛盾が起きるの
が過去ログで言われていたような問題なのではないかと思います。

(?\tag-number)に限らず、２行目以降にマッチすること自体がカーソル位置から
の移動で矛盾を生むようです。
過去ログにもありましたが、検索文字列が「a\nb*」の場合は、もしかしたら案1
ができるとしたら解決するかもしれないですが、案1は無いとすると２行目以降マ
ッチの解決にはならなさそうです。

>　(「aaabbb\n\n」が成功し「(?\3)(aaabbb)(\n)(\n)」が失敗するのは直感的でな
>　い)

と書かれているので２行目以降マッチへの解決策という意味ではなかったでしょ
うか。
そうだとしたらどういうメリットがあるのかちょっとよくわかりませんでした。

RE:04596 タグ付き検索の仕様

秀丸担当 さん　09/11/27 15:09

いろいろ検討してみたのですが、正規表現内にコメントを書けるようにして、秀
丸エディタ独自の判断を指示するようなことができるといいんじゃないかと思い
ました。
（以前にも似た話がでかかって消滅していたような気もしますが）

この件以外にも、以前に検索対象とする行数を指定したいというようなこともあ
り、そういったことにも秀丸エディタ側に事前にコメント解析することで対応で
きそうです。

例えば…

●コメント
(?#コメント)

●ヒットする対象となる行指定
(?#targetline:2)とか(?#fulllinematch)

これで、
(?\2)(xxx)\n(yyy)
ができなかったのが、
(?#targetline:2)(?\2)(xxx)\n(yyy)
とすることで可能になるとか。
あるいは、(?#fulllinematch)といった感じで行数指定ではなく改行超えても常に
ヒットするようにするとか。

●検索バッファに取り込む行数
(?#lines:10)

これで、
\n+
が連続行でできなかったのが、
(?#lines:10)\n+
とすることで10行まで可能になるとか。

うまくいくかどうかやってみないとわかりませんが、そういった感じで検討して
みようと思います。

RE:04602 タグ付き検索の仕様

カモノハシ さん　09/11/28 14:56

こんにちは、いつもお世話になっております。カモノハシです。
まとめて、こちらへ返信させていただきます。

> >[案1]複数行検索の充実
>
> まずコールバックという新たな仕組みを作るとしたら、既存の仕組みを大きく変
> えなくてはいけないと思うので、利点に対してのコストが大きすぎると思われま
> す。
> とても長い行数が対象になる場合など、おっしゃられているような問題点のこと
> も考えると現実的ではないように思います。
そうですか、残念です。

> >[案2](?\tag-number)形式の2行目以降のマッチに最適化
>
> HmJre.dllで２行目以降へのマッチ自体はできていて、マッチするかどうかという
> 点はあまり問題ではないようです。
> カーソル位置からの上下移動で、相対的な移動先とヒット回数で矛盾が起きるの
> が過去ログで言われていたような問題なのではないかと思います。
>
> (?\tag-number)に限らず、２行目以降にマッチすること自体がカーソル位置から
> の移動で矛盾を生むようです。
> 過去ログにもありましたが、検索文字列が「a\nb*」の場合は、もしかしたら案1
> ができるとしたら解決するかもしれないですが、案1は無いとすると２行目以降マ
> ッチの解決にはならなさそうです。
>
> >　(「aaabbb\n\n」が成功し「(?\3)(aaabbb)(\n)(\n)」が失敗するのは直感的で
> >　ない)
>
> と書かれているので２行目以降マッチへの解決策という意味ではなかったでしょ
> うか。
> そうだとしたらどういうメリットがあるのかちょっとよくわかりませんでした。

「２行目以降にマッチする」から、問題なんですよね？
で、「aaabbb\n\n」のような検索は、マッチする先頭が一行目にあるから、問題な
い。
だから、「(?\3)(aaabbb)(\n)(\n)」が指定されたら、一度「(aaabbb)(\n)(\n)」と
いうパターンで検索して、そのマッチした文字列に対して、さらに絞り込みの意味
で、「(?\3)(aaabbb)(\n)(\n)」を検索する。
という趣旨でした。
で、不一致検索の問題があるので、絞り込むときの文字列は「(aaabbb)(\n)(\n)」
がヒットしたときの文字列をもう一度渡せば良いはず。

あ、ちなみに、「(aaabbb)(\n)(\n)」で検索するときは、マッチする先頭が2行目以
降にあるときだけ、検索成功とする、従来通りの検索です。

なにか、見落としがあるのでしょうか。

> ●ヒットする対象となる行指定＋ ●検索バッファに取り込む行数
こちらは、非常にむずかしい気がします。
ヒットする位置が検索前に判明するとは限らないので、(?#fulllinematch)を多用す
ることになり、その結果、例の2行目以降マッチ問題が顕在化してしまうような？

ところで、2行目以降マッチ問題の根本は、マッチ範囲の終端と渡した文字列の終端
が一致するときにのみ発現する、という理解でいいのでしょうか。

# 以下は終端一致問題とすり替えることができる前提です。
上記の[案1]の改変版の提案です。
通常に検索して、マッチ範囲の終端と渡した文字列の終端がかさなる結果が得られ
た場合には、DLLに渡す文字列を+1行してみる。
ってのはいかがでしょうか。

前提が間違っていると無駄なので、あまり細かくは考えていませんが。

RE:04612 タグ付き検索の仕様

秀丸担当 さん　09/11/30 11:08

>「２行目以降にマッチする」から、問題なんですよね？
>で、「aaabbb\n\n」のような検索は、マッチする先頭が一行目にあるから、問題な
>い。
>だから、「(?\3)(aaabbb)(\n)(\n)」が指定されたら、一度「(aaabbb)(\n)(\n)」と
>いうパターンで検索して、そのマッチした文字列に対して、さらに絞り込みの意味
>で、「(?\3)(aaabbb)(\n)(\n)」を検索する。
>という趣旨でした。

手法そのものは理解できるのですが、この手法によって何が解決されるのか、目
的がわかりませんでした。

２行目以降にマッチする問題をしないように解決するという意味でしたら、現状
で表面的にマッチしないように処理されているので、問題にはなっていないです。

２行目以降にマッチしないのが問題なのでマッチするように解決するという意味
でしたら、マッチそのものはできますがそれに伴うカーソル移動等の問題が解決
できるかどうかわからないです。

>ところで、2行目以降マッチ問題の根本は、マッチ範囲の終端と渡した文字列の終端
>が一致するときにのみ発現する、という理解でいいのでしょうか。

これ以外にも何か問題があるかもしれないです。
少し試してみた限りでは、
(a)\n(a)(?\2)
で、
a
a
a
a
a
というテキストに対して、下検索の連続では１行置きにヒットし、上検索の連続
では１行ずつヒットするという食い違いが見れました。
いままでヒットしないようにされていて触れられていなかったので、他にもあっ
た問題がいろいろ表面化するかもしれないです。

>ヒットする位置が検索前に判明するとは限らないので、(?#fulllinematch)を多用す
>ることになり、その結果、例の2行目以降マッチ問題が顕在化してしまうような？

多用すると問題が顕在化してしまうかもしれません。
おそらく改行以降にヒットする場合のみに限定的に使い、多用されることは無い
と思うのですが、あまり問題になるようでしたらやめたほうがいいのかもしれな
いです。

RE:04636 タグ付き検索の仕様

カモノハシ さん　09/12/02 00:48

こんばんは、いつもお世話になっております。カモノハシです。

> 手法そのものは理解できるのですが、この手法によって何が解決されるのか、目
> 的がわかりませんでした。
(snip)
> ２行目以降にマッチしないのが問題なのでマッチするように解決するという意味
> でしたら、マッチそのものはできますがそれに伴うカーソル移動等の問題が解決
> できるかどうかわからないです。
あ、なるほど。
「２行目以降にマッチしないのが問題なのでマッチするように解決する」のつもり
でした。

で、カーソル移動というか、上候補/下候補の問題ですよね。
たしかに、こちらが解決するか不透明です、検討不足でした。申し訳ありません。

とどのつまり上候補が、「先頭から検索した場合の一つ前のマッチ場所」とするか、
「カーソル位置から逆方向に検索した場所」とするか、の違いですよね。
ご指摘の、(a)\n(a)(?\2) 問題も。

たしか、こちらの会議室のどこかで、この種の議論が過去にあったように、記憶し
ていますが、探し出せませんでした。
たしか、「一つ前のマッチ場所」とすべきって結論だったような記憶がありますが。

現時点で、
「a b c d e 」　　　　　　という文字列に対して、
「([a-e]) ([a-e])(?\2)」　とか、
「(?<=[a-e] )[a-e]」　　　とかで検索すると、そういう動作になるのですが、こ
れは、どういう検索方法で実現されているのかが、分かりませんでした。
ちなみに、現在でも、上記文字列の途中から検索すると、対応しません。
(複数行の検索では、これが常に発生することに問題があるのかな？)

ぱっと思いつく方法は、(?\tag-number)が使われたら、それがないものとしたマッ
チ範囲を覚えておき、それを利用する方法ですが、複雑すぎて難しそうですね。

う～ん。勝手に提案しておいてなんですが、頭がパンクしそうですね。
「秀丸エディタ側のコメント解析」がベターな気がしてきました。

とりあえず、ですが、ヘルプファイルに注意書きを入れていただければ幸いです。

カモノハシ

RE:04664 タグ付き検索の仕様

秀丸担当 さん　09/12/02 11:37

>「２行目以降にマッチしないのが問題なのでマッチするように解決する」のつもり
>でした。

そうでしたか。
言われていることが理解できました。ありがとうございます。

>ちなみに、現在でも、上記文字列の途中から検索すると、対応しません。
>(複数行の検索では、これが常に発生することに問題があるのかな？)

そうですね。現状でも一行内の開始位置が違うと、(a)\n(a)(?\2)と同じような問
題はあるようです。
行単位だとそれが顕著に現れやすくなるということだと思います。

コメントの解釈で秀丸エディタ独自に処理することができるようにして、制約が
あるということをヘルプに書いておくというのが妥当ではないかと思いました。
β28でそのようにしてみようと思います。