n+ が改行を一つしか拾わない

連続する改行を含むファイルを開いて，正規表現 n+ で検索しても，改行を一つしか拾わないようです。 ちなみに，nn では二つ，nnn では三つ，連続する改行が正常に検索できます。 n と 量指定子 + の組み合わせに問題があるのではないかと思いますが，いかがでしょうか。

すみません，この件は正しくは「EmEditor 本体の不具合の報告」のほうへ書くべきでしたでしょうか？ ちなみにバージョンは「Version 12.0.0」です。

redakt55 様 いつも EmEditor Professional をお使いいただき、誠にありがとうございます。 改行を検索する場合、[ツール] メニューの [カスタマイズ] を選択し [検索] タブで、[正規表現で検索する追加行数] テキスト ボックスに、1 以上の検索に必要な行数を指定してください。 ご確認をいただけると幸いです。 どうぞよろしくお願い申し上げます。

確認できました。確かにその通りになりました。 また，ヘルプの「[正規表現で検索する追加行数] テキスト ボックス」を読んで，この設定の意味がほぼ理解できました。 もう少し理解を深めたいのですが，たとえば abc[改行]def[改行]ghi という 3 行からなるテキストがあり，カーソルがテキスト先頭にあったとき，以下のような動作と思ってよいのでしょうか？ ・追加行数が 0 の場合，「正規表現の関数」に渡す実引数は「abc[改行]」ではなく「abc」 ・同じく 1 の場合，渡す引数は「abc[改行]def」 任意行数の複数行検索ができないと困るので，ここに「9999999」みたいな数値を入れて使うことになりそうです。 なぜこんな仕様になっているのですか？ ユーザーがここに「1」とか「2」とか「3」といった値を入れる場面が思いつかないのですが。

redakt55 様 いつも EmEditor Professional をお使いいただき、誠にありがとうございます。 この設定の意味は、理解されているので合っていますが、正規表現に n が含まれている場合は、2 行以上のテキストを正規表現の関数に渡すことがあります。 「9999999」などを指定すると、巨大ファイルを検索する場合に、検索が著しく遅くなることがあります。そこで、既定の行数を少なくしているわけです。 どうぞよろしくお願い申し上げます。

レスに気づくのが遅れました。ご回答ありがとうございます。 検索が遅くなるケースについてさらにご質問します。 ある巨大ファイルで，「追加行数」を非常に大きくしたとき，実際に検索が著しく遅くなったとします。 このような条件下では，「ファイルから検索」においても検索は著しく遅くなるのでしょうか？ 「ファイルから検索」は，行単位でなくファイル全体を正規表現の関数に渡すわけですよね？

redakt55 様 いつも EmEditor Professional をお使いいただき、誠にありがとうございます。 その通りです。[ファイルから検索] の場合は、この数字は関係ないです。 どうぞよろしくお願い申し上げます。

すみません，知りたかったことは，「ファイルから検索」の場合に同じ原因で動作が遅いことがあるのかどうか，です。 ファイルを開いて検索をかける場合，ファイルの中身全体を正規表現の関数に渡すのでは動作が遅くなることがあるわけですよね？　であれば，「ファイルから検索」の場合も遅いのかな，と思ったわけです。

redakt55 様 いつも EmEditor Professional をお使いいただき、誠にありがとうございます。 ファイルから検索の場合は、遅くなりません。難しい話になるので、あまり詳しく書くのは避けたいと思いますが、将来のバージョンでは、最適化のために、今書いていることも変わっていることはあり得るかと思います。 どうぞよろしくお願い申し上げます。

分かりました。それで安心しました。