フォーラムの返信を作成しました。
-
投稿
-
江村様
いつもお世話になっております。
yasujiです。もし、攻撃的な内容だと感じさせてしまっていたら、この点は申し訳ありません。正確にコンパクトに書くように意識して技術的な話だったため、端的な表現を多く使用して社交辞令的なことなど余計なことは省いて書いておりました。
「誠意を持ってお答えしている」とのことですが、江村様の過去の対応がありますので、正直なところすぐには信じることはできません。こればかりは、今後とも継続していただくことで徐々に信じれらるようになると思います。
RAMが32GB以下だと絶対に開けないわけではなく、64GB以上なら必ず開けるというものでもありません。ファイルサイズに加えて、行数や仮想メモリーの量など、他の要因も影響します。実際には、ファイルサイズは開く速度に影響しますが、開けるかどうかは行数が大きな要因です。また、ファイルを開くだけで編集しない場合は、一時フォルダの空き容量は不要です。
私は、「1TB～16TBのテキストファイルを開く」という操作について、下記の通りに理解しましたが、正しいでしょうか？
——
ユーザのPC環境（メモリサイズ、仮想メモリ設定、その他）によって、開ける最大ファイルサイズが決まるので、明確な説明ができません。
ただし、一時フォルダの空き容量は、ファイルを開くだけで編集しない場合は 0 [Byte] で問題ありません。
——
「また、ファイルを開くだけで編集しない場合は、一時フォルダの空き容量は不要です。」が、正しいというならば「〔致命的バグ〕メモリ不足でもファイル読込を停止しない」の事象はどのように考えた良いでしょうか？
この事象は、私が[ディスクベースを有効にする(B)]をOFFに設定したことが悪かったということでしょうか。一般的なアプリでは、「16GB～32GBは自動割り当て（手動設定する場合は物理メモリの半分）」で問題ないかもしれません。しかし、EmEditorで巨大ファイルを扱う場合は、この設定では不十分で、80GB以上の仮想メモリーを推奨します。理由として、EmEditorは巨大ファイルを開く際に大量のヒープメモリーを必要とし、Windowsの仮想メモリーの増加速度が追いつかないため、メモリー不足が発生しやすい状況です。この問題は、Visual C++でCode Analysisを使用してビルドする際にも発生しやすいです。詳細は以下のWebページをご覧ください。
このように、大きなメモリーを必要とするアプリでは、あらかじめページングファイルの初期値を大きく設定しておく必要があります。私はこれをOSの問題と考えています。
大きなメモリーを使用するアプリケーションには、現時点でOSに問題があると考えられているので、それを軽減または回避するために上記のページングファイルサイズを推奨していると理解しました。
宣伝と思われるかもしれませんが、事実を記載しており、誇張ではありません。「メモリの許す限り」との注記もあります。事実を伝えないとユーザーに正しい仕様が伝わりません。EmEditorの仕様や機能をWebサイトに明記することが重要だと考えています。「8GB～32GBのRAMを搭載した一般的なPC」という指摘はその通りですが、EmEditorユーザーの中には64GB以上、さらには256GB以上のRAMを搭載したPCをお持ちの方も多くいらっしゃいます。EmEditorは、ユーザーの要望に応じて巨大ファイルを扱えるように長年改良を重ねてきました。これは決して「カタログスペックの見栄えを良くするためだけの機能」ではなく、多くのユーザーがこの機能を求めてEmEditorを選んでくださっています。
EmEditorのユーザの中には、256GB以上のRAMを搭載したPCをお持ちの方が多くおられて、そういったユーザのニーズで巨大ファイルを扱う機能を改良してたということは理解できました。
そうであれば、HPの宣伝のページに江村様がご回答いただいた内容を整理して書かれたら、私のような128GBのRAMでは、巨大ファイルを扱うのは難しいと理解できるようになりよりよくなると思います。ここまで、江村様の誠意を受けて、正直ベースで私が理解できた内容で返信を書かせていただきました。
まだ、16TB対応の機能についてわからない点があり、追加で質問させてください。（Ｑ１）[カスタマイズ]->[高度]の中にある[最大メモリサイズ(Y)]というのは、EmEditorがファイルを開く際に使用できる最大物理メモリサイズだと考えていましたが、これは私の理解の誤りでしょうか？もし理解の誤りならばどのような設定なのか説明ただければと思います（「〔致命的バグ〕メモリ不足でもファイル読込を停止しない」のケースで[最大メモリサイズ(Y)]でファイル読込停止または、エラー表示のいずれもしなかったため）
（Ｑ２）下記のPC環境だと仮定して、enwiki-20241020-pages-meta-current.xml（このトピックの最初の投稿）を開くことが可能でしょうか？また、一時フォルダの容量はどのくらいあるとよいのでしょうか？（EmEditorでの操作内容：このファイルを開き、キーワード検索して必要な情報を選択コピー（見つけた情報量によるが1000文字程度）して、新規作成テキストへ貼り付けて、新規テキストを保存して終了する）
〔PC環境〕
OS: Windows 10 64bit クリーンインストール、現時点までのWindows Update済み。
RAM: 32GB
HDD: 8TB(C Drive only)よろしくお願いします。
江村様
いつもお世話になっております。
yasujiです。そのようなことは思っていません。修正を拒絶することはありません。どうして、yasuji様は、そのように感じられるのでしょうか? もし、私の書き方が、yasuji様に、そのような印象を与えてしまったのでしたら申し訳ありませんでした。
先ほど公開した v24.4.902 にて修正いたしました。
修正いただきありがとうございます。確認は別途いたします。
「どうして、yasuji様は、そのように感じられるのでしょうか?」については、下記の通りです。
１．過去の検索（置換）ウィンドウの切替キー操作時の不具合についてのメールでのやり取りの「#31387 – 〔要回答〕報告済：検索（置換）ウィンドウの動作不具合」において、ユーザのお好みの動作が異なるという理由と、この方法で代替できますよというご説明で修正をお断りされました（実際に修正いただいたのは、このメールの内容をトピック作成した後でした）。私個人としては、他のテキストエディターができていることで、無理を言っているつもりはなく、このような説明で修正を拒絶されたと受け止めて、かなりショックでした。
２．「ここ最近のEmEditorのリリース情報について」のトピックにおいて、「不具合は非常に軽微なもの」としてご説明しておりましたが、追及した結果、その非常に軽微なものの中に２バージョンでクラッシュバグが合計５件も含まれていたことが判明し、かなりショックでした。上記の２つが今回私の対応の背景になります。
これは、使用されているフォントのデザインの問題です。設定のプロパティの [表示] ページの [行間] で調節可能です。ここには -1 のように負の値を入力することもできます。ただし、行頭の全角空白（U+3000）の四角記号の左側が欠けて表示される問題は、こちらでは既に修正しました。次に公開されるバージョンでは修正されています。
上記のご回答は、まず問題点と代替案を説明して、次の「ただし、」からは私が記載した（２）の四角記号の表示が欠ける問題について修正したと説明しています。
私の中での説明文は、フォントの問題でEmEditorの問題はないので不自然な行間表示は提示した方法でユーザ側がご対応ください、（２）は次に公開されるバージョンで修正しました、（３）については記載がないので修正するつもりはない（穏便に記載漏れとしました）と理解しました。
過去の江村様のご対応の１．と２．については私の中では強く記憶していたため、私の中でまた１．と同じ対応（言い訳めいた理由を書かずに）を繰り返すのかと怒りが沸き起こりそのように書いた次第です。以上が私の回答内容になった理由です。
江村様
いつもお世話になっております。
yasujiです。ご回答ありがとございます。
（Ｑ１）
ご指摘の通りです。（Ｑ２）
その通りです。了解しました。
（Ｑ３）
500行ごとに進捗を更新するように最適化しています。不具合ではありません。それでは、「根拠は、[スレッド数(N)]を 2 に設定して、上記同様の検索を実行すると、「000」または「500」の表示に固定されずに表示されるため。」と記載しましたが、[スレッド数(N)]が2の場合は、 下3桁の数値が「062」や「489」などのように表示されるのはなぜでしょうか？ご説明とこの場合の表示方法が一致しません。
（Ｑ４）
検索用スレッド数が[スレッド数(N)]が1の場合、内部ではその値に1を足して2スレッドで検索しているのではないかというご質問ですが、これは考えられません。そうすると、EmEditorは、Unicode未対応のBoost.Regexの正規検索エンジンをどのようにUnicode対応させてNotepad++よりも高速に処理できるのでしょうか？
私の考えだと、（１）Boost.Regexのソースコードに改良加えてUnicode対応している、（２）Boost.RegexとICUの代わりを独自実装してUnicode対応しているのいずれかをしているのかと思います。
長年高速処理を追求し続けて改良を加えられているので、検索エンジンについても説明いただければ、大きなセールスポイントになると思います。よろしくお願いします。
江村様
いつもお世話になっております。
yasujiです。ご回答ありがとうございます。
これでようやく16TBファイルの対応について下記の通り理解ができました。1TB～16TBのテキストファイルを開くには、RAMは64GB以上、一時フォルダの空き容量は170GB～2716GB（ファイルサイズの約16%）が少なくとも必要だということが分かりました。
したがって、1TB未満のテキストファイルについても、同じ傾向があると考えられます。
8GB～32GBのメモリを搭載したPCは、1TB～16TBのテキストファイルは開くことはできない、1TB未満のテキストファイルはユーザ自身でメモリの空き容量と上記の要件を考慮して開く必要があるということで理解しました。なお、「仮想メモリを増やす方法」で、ページングファイルサイズを80000MB(80GB)にするように推奨されております。しかし、通常のページングファイルサイズの設定値は、8GB～16GBは搭載物理メモリと同じサイズ、16GB～32GBは自動割り当て（あえて手動設定する場合は、搭載物理メモリの半分のサイズ）に設定するのが良いとされています（ページングファイルサイズをいくら大きくしてもRAMを増やしたことにはならず、RAMの一部を補う程度のため）。
HPに記載されている「16 TB までのファイル」の宣伝は、EmEditorのカタログスペックの見栄えを良くするためだけの機能だということが分かりました（8GB～32GBのRAMを搭載した一般的なPCでは開くことができないというご回答のため）。
江村様
いつもお世話になっております。
yasujiです。これは、使用されているフォントのデザインの問題です。設定のプロパティの [表示] ページの [行間] で調節可能です。ここには -1 のように負の値を入力することもできます。
冒頭に「Windows標準のメモ帳(notepad)で同じフォントを設定した場合の表示には不自然な表示はない。」と記載したのは、フォント特有の表示を考慮するために、メモ帳の表示状態を基本にして、その表示状態と比較してEmEditorは明らかに行間の空白が大きすぎるので、表示不具合だと説明しています。ちなみに、サクラエディタ32bit Ver. 2.4.2.6048 Appveyor (a3e63915b)でも、メモ帳とほぼ同じ状態で表示されます（この程度の表示であれば何の問題もありません）。
修正を拒絶する理由は、修正工数が大きすぎてかつ複雑なため、やりたくないからでしょうか？
それとも、過去の「#31387 – 〔要回答〕報告済：検索（置換）ウィンドウの動作不具合」と同じ理由でしょうか？記載漏れだと思いますが、下記の修正もお願いいたします。
（３）半角空白（U+0020）の記号が縦方向に伸びて表示される（Windows標準のＭＳ ゴシックを基準）
よろしくお願いします。
江村様
いつもお世話になっております。
yasujiです。（質問1）
こちらのリンク
/text-editor-features/large-file-support/files-up-to-248gb/
にある画面図の通り、15.9 TB、17,592,101 行の ASCII ファイルを処理するのに、83,190.860秒かかりました。使用したPCは、確かWindows 10 (64-bit)、Core i9-9900K、64GB RAM、2TB SSDだったと思います。ファイルが保存されているディスクは、Western Digital の 18TB ハード ドライブ (WD181KRYZ) です。上記のご回答ありがとうございます。しかし、「16TBファイルを開くのために必要な空き容量」（＝開く処理が完了した時点での一時ファイルの合計サイズ）、「Windowsの仮想メモリ設定内容」の情報が不足しておりますので、ご提供をお願いいたします。
もし、手元に記録がないようでしたら、お手数ですが、再度同様の検証をいただいて、情報提供いただきたいです（PC環境が変わればそれらの情報も）。（質問2）
ファイルのサイズよりも、行数が重要になります。つまり、1行あたり1000文字のファイルよりも、1行あたり10文字のファイルの方が、より多くのメモリを必要とします。ファイルを開くことに失敗する場合は、仮想メモリを増やす必要があります。仮想メモリの増やし方については、こちら
/increase-virtual-memory/
を参考にしてください。デフォルトの設定の通り、「ディスクベースを有効にする」がオンになっていれば、ファイルを開くだけで編集が不要な場合、一時ファイルの作成は必要ないはずです。答えていただきたい回答になっていません。私の（Ｑ２）の質問のみを抜粋して下記に再掲いたします。再度回答をお願いします。
一般的なデスクトップＰＣに搭載されている8～32GBのメモリサイズで、1TB～16TBのファイルを開くことができるのか？
物理メモリをすべて使用するなどでWindowsシステムへの悪影響の有無はあるのか？
について、情報を開示いただけますでしょうか？
江村様でしたら、EmEditorの開発者ですので、必要とする物理メモリサイズ、一時ファイルサイズを正確に計算することができると思います。よろしくお願いします。
江村様
いつもお世話になっております。
yasujiです。ご提示いただいたブログの説明とリンク先の内容を確認しました。
確かに、私がバグだと報告した動作が、v23.1の動作仕様通りであると理解しました。その動作仕様で確認です。
EmEditorを動作させたPC環境がC:しかなく、そのC:に開きたい200.3GBのXMLファイルがあり、[一時フォルダ(F)]はデフォルトのままだとします。
この状況下でEmEditorを起動して、200.3GBのXMLファイルを開くと、メモリ不足、ページファイル不足になり、[一時フォルダ(F)]のパスに一時ファイルを大量に作成して、最終的にはファイルを開く処理が完了して編集可能な状態になる。ただし、メモリ不足分のデータが、一時ファイルとして書き出された状態です。当たり前ですが、ファイルを編集しようとしてスクロールしたり書き換えたりすれば、その一時ファイル（ページファイルも含む）の読み書きが発生します（メモリに読み込まなければ処理できません）。HDDであれば、読取速度と書き込み速度はメモリより圧倒的に遅いです。（高速転送できるSSDを前提にしないでください。すべてのユーザが高速なSSDを持っているとは限りません）
「v23.1 では、メモリに関連するアルゴリズムを見直し、より効率的な動作を実現しました。」とありますが、HDD上の一時ファイルならびにページファイルを使うことは処理速度の低下を招くことは自明なのですが、どうして効率的な動作が実現できるのでしょうか？リンク先の文章を改めて読んでみたところ、とんでもないことが書かれておりましたので確認させてください。引用された文章の中にも含まれています。
「仮想メモリのサイズに気を遣わずとも、メモリ不足によるクラッシュの頻度を大幅に軽減することができました。」と書かれておりますが、これはv23.1をリリースした時点で、そのバージョンにはメモリ不足を契機としたクラッシュバグがまだ存在していますと江村様は認識してリリースしたと理解しました。実際に、「置換で改行が増加するとクラッシュする」で発生しております。この報告内容の事象で本当に江村様の下記のご説明は、間違いなく検証されて保証されているのでしょうか？Windowsの動作が不安定になったり、BSODの心配はありません。
よろしくお願いします。
江村様
お世話になっております。
yasujiです。Emurasoft, Inc.のご回答として理解いたしました。
言うべきこと言って、聞くべきことを聞きましたので、もはやすることはなくなりました。
あとは、他のユーザにお任せいたします。江村様
お世話になっております。
yasujiです。こちらにエムソフト カスタマー センターのログイン情報を入力してください。
https://support.emeditor.com/ja/
こちらのメールアドレスとパスワードを使用します。フォーラムのログイン情報とは異なります。一度ログインしていただければ、その後はメールアドレスやパスワードなしで、以前と同じダウンロード一覧の画面にアクセスできます。お試しいただけると幸いです。
上記のURLを開いて表示される項目のうち「製品の登録」をクリックして開いたところ、画面に下記の説明が表示されました。
製品の登録
販売店より購入された登録キーは、使用する前に製品登録する必要があります。
まだアカウントをお持ちでない場合、このページの後、アカウントを作成します。
ご購入から 30 日以内に製品登録を完了する必要があります。古い登録キーは認識されません。
EmEditorのHPから購入した永久ライセンスを持っていますが、2Checkoutの注文詳細を確認すると「ご注文日:2021-10-23」となっております。
このケースですと、登録不可能ということでしょうか？
上記のページから製品登録をした記憶がなかったので。。。（２）ＩＤ／パスワードを要求する仕様変更について、「ブログ」で事前告知および現在に至るまで説明をしなかった理由
セキュリティ上の問題により、直ちに実行する必要があり、正規ユーザーであればログインして問題なく使用できるため、事前告知は必要ないと考えました。私たちは古いバージョンをサポートしておらず、古いバージョンのダウンロード提供はあくまでお客様へのサービスです。以前は提供しておらず、今後も永遠に続くとは限りません。将来、予告なくサービスを終了する可能性がありますので、あらかじめご了承ください。
事前告知しなかった理由は理解しました。
「現在に至るまで説明をしなかった理由」が書かれておりません。セキュリティ上の問題（DoS攻撃（サービス拒否攻撃）の可能性があるため）であれば、対処された後にセキュリティ対策で正規品購入者のみのアクセスに制限したこと、正規品購入者はアクセスするためにはどのような手続きが必要かを「ブログ」の記事で知らせることができたはずです。なぜ、「ブログ」で現在に至るまで説明をしなかったのでしょうか？
ユーザに対して事情説明を一切せずにある日突然アクセスできなくなって、私を含めて困ったユーザが多く出てしまいます。
「今後も EmEditor の開発に集中し、より良いソフトウェアの開発とサポートの充実に全力を注いでいく所存です。（ライセンスの価格改定と、永久ライセンスの販売終了について (2023年7月26日)）」と書かれています。ユーザサポートにはユーザに対して事情説明をすることも含まれていると思うのですが、これは私の考え違いでEmurasoft, Inc.としての「サポートの充実に全力を注いでいく」には含まれていないということでしょうか？
どうしてyasuji様がそのような考え方をされるのか、私には全く理解できません。何か都合が悪いとか、そういうことは全く関係ありません。あくまでも、セキュリティ上の問題です。
2023年まで遡ります。当時はメールにて不具合報告と修正をお願いしていましたが、江村様から下記の(S1)～(S3)ような「ユーザサポート」を受けていたことが根本的な理由です。
(S2)のメールについては、江村様からの返信がないにも関わらず、フォーラム上の「EmEditor v23.0 preview (22.9.901-)」で多数の不具合が修正されている状況でした。ここには書くことができない深刻な不具合が見つかって、かつ過去のバージョンから存在し続けていたことが判明したために、発覚を恐れて速やかに、アクセス制限を設定して事情説明を一切せずにアクセスできるユーザを限定して、問題を隠ぺいしたのではないかと疑いました。
したがって、本当の理由を確認したかったのです。(S1) #31387 – 〔要回答〕報告済：検索（置換）ウィンドウの動作不具合（左記メール受信日：2023/11/15、初回メール報告日：2023/11/09）
==>メール連絡で「これは、ユーザーによって好みの動作が異なると思います。」という理由で不具合修正を却下されてしまいました。(S2) 新規の正規表現の不具合２件（22.9.910においても発生）（初回メール報告日：2023/11/14）
==> 2024/01/16 0:00(JST)まで一切の返信がなく、この問題を他のユーザに知らせるためにこのフォーラムに参加する契機になりました。(S3) #31391 – 新規の正規表現の不具合２件（22.9.910においても発生）（左記フォーラム回答日：2024/1/16、初回フォーラム投稿日：2024/1/16、初回メール報告日：2023/11/14）
==> 「報告済：正規表現検索に関する不具合２件（初回メール報告日：2023/11/08）」のメールで添付したjsファイルのうち、１つと全く同一の内容のファイルです。このメールは、正常に受信できてコミュニケーションが取れているのに、数日後に送信した「新規の正規表現の不具合２件（22.9.910においても発生）」のメールだけ消失することはあり得ないです。メール転送失敗のエラーメールの受信もしていません。また、メールサーバ上にウイルス対策ソフトが稼働していたとしても、２件のメールのそれぞれの添付ファイルだけを削除するか、メールごと削除するかの動作にならないとおかしいです。いつもお世話になっております。
yasujiです。ご検討いただきありがとうございます。
さっそく、提示いただいたマクロをv24.3.906で試したところ私の希望通りの動作をしました。
ただし、検索を繰り返して行う作業ではクリップボードの内容を変更できない制約がつくので、それを踏まえて活用させていただきます。いつもお世話になっております。
yasujiです。OnigSyntaxPerl (Perl 5.10+) を指定しています。
使用できる正規表現の多いものを指定していただきありがとうございます。気にしていたことが解消できて安心できました。
よろしくお願いします。
いつもお世話になっております。
yasujiです。申し訳ありません。ひとつ前の確認の内容に記載ミスがありましたので修正いたします。
OnigurumaとOnigmoのソースコードのPrefixがOnigと表記されて同じで取り違いないようにするため、Onigmo側のPrefixのOnigをOnigmoへ置換して確認していたものをそのまま書いてしまいました。OnigmoSyntaxPerl58 ==> OnigSyntaxPerl58
OnigmoSyntaxPerl58_NG ==> OnigSyntaxPerl58_NG
OnigmoSyntaxPerl ==> OnigSyntaxPerl修正して下記に再掲いたします。
—————————-
追加された「Onigmo.Perl」について確認があります。
「Onigmo.Perl」は、Onigmoのソースコードregsyntax.cに示されている OnigSyntaxPerl (Perl 5.10+) を指定しているのでしょうか？Onigmoは、OnigSyntaxPerl58 (Perl 5.8)、OnigSyntaxPerl58_NG (Perl 5.8 + named group)、OnigSyntaxPerl (Perl 5.10+) の３つのPerlバージョンのPerl文法をサポートしており、使える正規表現に差があるため。
もし、質問の回答が別のバージョンだった場合は、そのバージョンが同定できるように変更いただくのとOnigSyntaxPerl (Perl 5.10+)の追加をお願いしたいです。よろしくお願いします。
いつもお世話になっております。
yasujiです。追加された「Onigmo.Perl」について確認があります。
「Onigmo.Perl」は、Onigmoのソースコードregsyntax.cに示されている OnigmoSyntaxPerl (Perl 5.10+) を指定しているのでしょうか？Onigmoは、OnigmoSyntaxPerl58 (Perl 5.8)、OnigmoSyntaxPerl58_NG (Perl 5.8 + named group)、OnigmoSyntaxPerl (Perl 5.10+) の３つのPerlバージョンのPerl文法をサポートしており、使える正規表現に差があるため。
もし、質問の回答が別のバージョンだった場合は、そのバージョンが同定できるように変更いただくのとOnigmoSyntaxPerl (Perl 5.10+)の追加をお願いしたいです。よろしくお願いします。
お世話になっております。
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が行すべてに一致する事象が発生するのは、１行ごとに正規表現の検索関数に引き渡している以外に起きえないからです。いつもお世話になっております。
yasujiです。７．〔仕様〕検索文字列の複数行表示に右端で折り返す機能をつけてほしい。可能ならデフォルトとして設定できEmEditorの再起動もその設定が残るようにしてほしい
理由：正規表現の初級レベルですと、１行あればたいてい事足りますが、上級以上になると複雑な長い正規表現文字列になることが多く、現状でEnterキーによる改行を入れる必要があります。この件につきましては、v24.3.905 にて対応いたしました。
EmEditor v24.3.905において、上記の要望していた機能が追加されかつ、下記の通りに確認できました。
[検索]／[置換]画面の[検索する文字列(F)]より右にある[>]ボタンを押下して、[複数行]を選択状態にすると、入力された文字列がテキストボックス内で自動折返し表示になることを確認しました。以前は、改行を意図的に入れる以外に複数行にすることができなく、検索実行時にその改行も検索対象となるため大変困っておりました。
ようやっと、まともに使えるものになってきて助かります。（[検索]／[置換]画面のサイズを変更できるにも関わらず、エディタ本体ができる自動折返しができないという状態だったので）
こういう細かいことをケアしているテキストエディターは他になくかなり困っておりました。追加で申し訳ないのですが、もし可能であれば、[検索]／[置換]画面の[検索する文字列(F)]のテキストボックスで、改行コード(CRLF, CR, LF)、半角スペース、タブを無視するオプションを追加してもらえるとありがたいです。一度の設定で３つをすべて無視する、個別にそれぞれの任意の組合せ（どれか一つのみ、どれか２つのみ）を設定して無視するがあるとさらにありがたいです。
正規表現を使用しているときに、丸括弧を多用することがあり、その対応付けミスで意図しない検索結果になったり、そもそもエラーになったりすることがあり、修正に時間がかかって困っております。
その対策として、テキストエディタ本体に貼り付けて、括弧の直後に改行を入れて、次の文字は半角スペースまたはタブでインデントを追加することで見やすくして記述ミスのデバッグをしている状況です。
イメージとしては、C/C++のif文を一行で書くか複数行で書くかと同じようなことをしています（どちらも文法違反ではないですが、後者は人間が理解しやすい）。
その見やすくした正規表現文字列をそのまま[検索する文字列(F)]のテキストボックスに貼り付けて、無視設定をして意図した検索ができると、貼り付け前に改行や半角スペース、タブの削除の手間がなくなってありがたいというのが理由です。私の知る限りでは、この機能を搭載したテキストエディタは見たことがありません。開発リソースの関係で難しいと思いますので、できなくても気にしません。
いつもお世話になっております。
yasujiです。EmEditor v24.3.905において、 正規表現エンジンのリストから「Onigmo.Perl」を選択することで、OnigmoのPerl文法が使用できることを確認できました。
念のため、「Onigmo.Ruby」は、６．を実施してRuby文法であることを確認しました。よろしくお願いします。
いつもお世話になっております。
yasujiです。EmEditor v24.3.905において、不具合がすべてのケースで下記の通り修正されたことを確認しました。
なお、正規表現エンジンのリストに「Onigmo.Perl」が追加されたため、従来の「Onigmo.Ruby」（元Onigmo）と合わせて念のため追加確認いたしました。５．結果の確認（v24.3.904で不具合解消済、再確認問題なし）
==> 修正されて不具合が解消されたことが確認できました。
追加確認：
「Onigmo.Perl」==> 不具合なし
「Onigmo.Ruby」==>不具合なし８．結果の確認（v24.3.903で不具合解消済、再確認問題なし）
==> 修正されて不具合が解消されたことが確認できました。
追加確認：
「Onigmo.Perl」==> 不具合なし
「Onigmo.Ruby」==>不具合なし１１．結果の確認
==> 一部不具合がまだ残っています。手順通りに再現できます。
９．の［検索する文字列］の２つのうち、一つにまだ不具合が残っています。
［検索する文字列］(Boost.Regexの場合)を使用した場合（v24.3.904で不具合解消済、再確認問題なし）
==> 修正されて不具合が解消されたことが確認できました。
［検索する文字列］(Onigmoの場合/Boost.Regexも可)を使用した場合
==> 修正されて不具合が解消されたことが確認できました。
「Onigmo.Perl」==> 不具合なし
「Onigmo.Ruby」==>不具合なし全てのケースでの不具合がすべて解消され問題なく動作することを確認しました。
迅速なご対応ありがとうございました。
いつもお世話になっております。
yasujiです。EmEditor v24.3.904において、不具合の修正結果を確認しましたが、下記の通り修正されたものと、未修正のものがあります。
５．結果の確認
==> 修正されて不具合が解消されたことが確認できました。８．結果の確認（v24.3.903で不具合解消済、再確認問題なし）
==> 修正されて不具合が解消されたことが確認できました。１１．結果の確認
==> 一部不具合がまだ残っています。手順通りに再現できます。
９．の［検索する文字列］の２つのうち、一つにまだ不具合が残っています。
［検索する文字列］(Boost.Regexの場合)を使用した場合
==> 修正されて不具合が解消されたことが確認できました。
［検索する文字列］(Onigmoの場合/Boost.Regexも可)を使用した場合
==> 不具合がまだ残っています。手順通りに再現できます。再度、ご確認とご対応をお願いします。
いつもお世話になっております。
yasujiです。承知しました。
これは不具合ではなくEmEditorの正常な動作なので、ユーザ様のほうで追加設定をして対応をお願いしますというご回答内容だと理解いたしました。2024年8月28日に年間サブスクリプション版の値上げを実施した状況で、このようなご対応でよいのでしょうか？
値上げ分の価値をご提供する何か新しいアイディアを当然持っておられると思いますが、それ以前に値上げ前のバージョンから存在している不具合またはユーザの使い勝手を改善して基礎になる品質を確保しなければならないと思います。
さらには、１年ごとに新価格で新テキストエディター（ユーザに継続更新をしていただくためには単品で売れるくらいの新機能がいるだろうと思いました）をユーザに購入していただけるだけの価値を提供していると確信されてて、その準備も進めていると思っています。その準備作業を一時的に止めて、不具合修正の作業をしても大きな影響はないように思いました。
もちろん、Emurasoft, Inc.としての江村様のお考えでですので、私としてはこれ以上追及するつもりはありません。さすがに、私も疲れてしまいましたので。
