お世話になっております。
yasujiです。
現在、[正規表現で検索する追加行数] の設定をなくすことを検討しており、実際に試しているところですが、まだ実現には至っておりません。実現までご不便をおかけして申し訳ありませんが、引き続き [正規表現で検索する追加行数] の設定を追加してご利用いただければと思います。現状では、巨大ファイルへの対応と正規表現を両立させるために、この設定が必要です。
上記の説明からの推測ですが、Onigmoに巨大ファイルデータを引き渡して正規表現検索の実行で何らかの不具合があってうまくいかないということがあるのかもとも思いました。Onigmo自体は巨大ファイルの検索のテストをしているかはかなり疑わしいので、経験則からの推測でしかありませんので、外れていたらすみません。
もし、Onigmo自体の動作不良か不具合が実現への障害になっているとしたらば、そこに関しては下記ようなやり方でクリアできるのではと考えました。
Onigmo（鬼雲）は、Oniguruma（鬼車）から分かれて開発された経緯がありますので、Onigurumaを追加サポートされてはいかがでしょうか？
メリットとしては、API関数等はほぼ同じで、引き渡すオプション定義などが違うだけのため、使い方はほぼOnigmoと同じで手間がかからないことかと思います。
ただし、OnigmoとOnigurumaのヘッダーの定義の名称がお互いほとんど同じ名称を使っているため、うまくすみ分けて実装する実装課題が出てしまいます。
前提条件として、Onigurumaが巨大ファイルの検索に耐えられることを事前検証する必要があります。
前提条件を満たしてかつ、実装課題を解決できる見込みがあれば追加サポートして、巨大ファイル検索機能を維持できるのではと考えた次第です。
Onigmoもそのまま機能は捨てずに、使用可能な最大ファイルサイズまでに制限して使えるようにする。それを超えて使用する場合は、現在のように１行ずつOnigmoに引き渡す方式を回避策として残して使用できるようにする（もちろんその回避策の実施内容とそれによる副作用や制限の説明が必要）。
Onigmoを残して不具合が修正されたときに巨大ファイルを検索できるように変更すればよいと思いました。
どうして「現在のように１行ずつOnigmoに引き渡す方式」と検索動作を認識していのかは、下記のニュース記事と不具合から確信しているため。
（１）INTERNET Watch – 「テキストの編集」にこだわりが凝縮！定番エディタ「EmEditor」はなぜ他のエディタと違うのか？（2020年2月3日）
「CPUの拡張命令やマルチスレッドを使って高速化！「80倍」も……C＋＋の「テンプレート」も活用した高速化も」の段落で検索アルゴリズムの高速化のやり方を江村様が説明しています。
（２）\A.+\Zを正規表現検索すると誤った検索を行う
\Aと\Zは、それぞれ入力テキストの先頭と末尾を示す正規表現です。したがって、「.(Dot)」が改行コードに一致するオプションを指定していないにもかかわらず、\A.+\Zが行すべてに一致する事象が発生するのは、１行ごとに正規表現の検索関数に引き渡している以外に起きえないからです。