- 投稿
2023/11/14に送付済みのこのメールについて、問い合わせるために過去の経緯のやり取りをすべてメール本文をコピーする形で投稿しました。
このメールについては、現時点2024/01/16 0:00(JST)において、何ら返信をいただいておりません（なお、誤ってスパムメールに分類されていないことも確認済みです）。
江村様にこの件について、問いただしたいことを返信する形で記載しますので、ご回答ください。なお、このメールを送信した段階では、EmEditor v23.0 preview (22.9.901-)の開発が進行していて、EmEditor v23.0のリリースを遅らせてでもその中で不具合の改修が行われるものと考えていました。
ところが、何事もなくあっさりとEmEditor v23.0をリリースされてかつ、その時点においても何らメール返信はありませんでした。対応する気がないのかと憤りを感じました。
しかしながら、これだけ詳細な不具合報告をしたので、リリース直後の既知の不具合と現在のステータス(2023/11/16時点のアーカイブ)に記載されるものと思っていましたが、それ以降から今日にいたるまで一切の記載がされません。
これは、正規表現を使用した検索／置換において、品質保証のためのテストを一切せずに今までこの致命的な不具合を放置してきたことを他のユーザに知られたくないためにまったく公開する気がないのだと、理解し怒り心頭にあります。
Emurasoft, Inc.の社長として、並びにその製品の開発の最終責任者としての江村様の対応は、まったく不誠実で誠意の欠片もありません。いくら、私から返信不要、結果で答えてと言われたとしても、最低限「ご迷惑をおかけして申し訳ありません。この不具合を改修いたします。」位のメールがあってしかるべきではないでしょうか？
日本おいては、三菱電機の製品の品質に関する不正検査問題や、ダイハツの本来テストすべきものをテストして合格したかのように偽って製品を出荷している不正問題が起きています。これらの企業は、多くの顧客からの信頼を失って大変なことになっています。
この不具合は、レアケースではなく正規表現を使用する他のユーザにおいても発生し得る深刻な不具合です。Windowsならばすぐに問題の情報と当面の回避策が出されるレベルです。
したがって、この不具合の存在を隠す意図が見えているため、フォーラムにてここに至る経緯を含めて一般公開して問いただすために投稿しました。
なお、この記事ならびに経緯の記事について、管理者権限を用いて削除するようなことも考慮して、念のためにアーカイブとして保存しておきます。
万一いかなる理由であっても削除された場合は、別のサイトにてこれらの今までの投稿した情報と併せて、事実ベースで記載させていただきます。
この不具合と、誠意のない不具合情報隠ぺいの対応についての情報は、購入検討しているユーザや、すでに購入済みで使用中のユーザにとって大きな影響があり、知るべき事柄で使用を中止して他のエディタへ乗り換えを検討するに値する内容です。下記の通り、EmEditorの不具合の多さと修正対応の悪さはユーザ間では周知の事実です。
くれぐれもご対応を誤らないようにお願い申し上げます。
〔報告日〕
2023/11/14〔報告方法〕
メールにて直接のタイトルの不具合の件を下記の内容で報告しました。〔報告内容〕
記載内容は、当時のコピーです。ただし、個人情報に該当する箇所は削除しています。対応した会社側の担当者の氏名のみ記載しています。
メールには、zipファイルを添付しておりますが、ここでは添付することができないため、テキストのみ記載します。対象：
EmEditor Professional (64-bit) Version 22.5.2
EmEditor Professional (64-bit) Version 22.9.910使用環境：
OS：Windows 10 Pro 22H2 64bit, OS ビルド:19045.3570From:
Sent: Tuesday, November 14, 2023 7:45 PM
To: Yutaka Emura
Subject: 新規の正規表現の不具合２件（22.9.910においても発生）江村様
いつもお世話になっております。
yasujiです。2023/11/08(JST)に報告した正規表現の不具合とほぼ同様の現象を引き起こす新たな正規表現の不具合を連絡します。
なお、この不具合については、前述した不具合が修正されているはずのEmEditor Professional (64-bit) Version 22.9.910でも発生することを確認しています。正規表現検索置換のバグが発生するたびに、本来の作業がとまり原因究明をさせられて腹がたっているため、長文ですが言いたいことを書きました。
正規表現検索・置換において応答遅延・不能などの不具合が発生しないように根本的な修正をしてください。この種の不具合が２０２３年においてクラッシュする不具合も含めて多発しすぎています。
江村様とのメールのやり取りの範囲ですが、どうも言われたことは言われた通りやるが、相手の趣旨や言いたいことをくみ取ることはできず、もしかしたら指摘された不具合の他のケースがあるかもしれないと考えて周辺の調査・検証ができていないように思います。（私は、過去にソフトウェア開発プロジェクトで品質管理担当の先輩から厳しく指導されて設計・テスト不備による隠れ不具合の怖さは骨身にしみついています。経験的に不具合の周辺に未知の問題が潜んでいることが多く、過去にその対応に失敗してお客さんの手に渡る前に、改修でき損害問題になることを回避できた経験があります）この不具合を契機にEmEditorがまともに使えないことが確定したため、Notepad++ v8.5.8 (64bit)に切り替えました。応答不能・著しい遅延で強制終了または終了をせざる負えず、失った編集途中のデータの回復、その問題を見越して、別ファイルに細かい経過保存をする手間が増えてしまい、思い通りに作業が進行できないためです。
今回の不具合は、以前に指摘した別パターンの正規表現で発生し、かつ修正されているはずの22.9.910でも発生して、EmEditorの不具合に対する対応に失望しました。お金を払って買ったソフトウェアで、このように同種の不具合が多発するのは初めてのことです。しかも、ここ１，２年で新規発売されたテキストエディターではなく、記憶の限りでは少なくとも登場してから１０年は経過しています。正規表現検索置換機能はかなり前から実装されていた機能で、なぜ初歩的な不具合が今頃になって発生するのか？非常に疑問です。EmEditorは、2023年8月30日から永久ライセンス価格が、税込み約6万円で販売されています。一方、Notepad++ v8.5.8は、無料です。CSVのエクセルライクな編集機能などの機能差異はありますが、Notepad++ v8.5.8で下記の不具合は起きませんでした。正規表現検索置換の機能に注目した場合において、Notepad++に負けるEmEditorの品質はいったいどういうことなのでしょうか？
それ以外にも、絵文字の表示不具合などテキストエディターとしての基本的な動作および機能に関して、ユーザから指摘がない限り修正をせず、自主的に品質を高めようという努力がないのが驚きです。2023年の初めに正規表現検索によるクラッシュ不具合の修正（表記上は様々なクラッシュを修正となっていました）がありましたが、私なら真っ青な顔になって、他の機能改善や不具合修正より最優先で関連するすべてのソースコードを検証して、原因を究明して場合によっては、コードを根本的に作り直すことをします。たとえ、時間が掛かってもです。なぜなら、テキストエディターにとって、検索置換機能は基本中の基本で不具合なくどのような入力に対しても正常に動作するのが当たり前だからです。テキスト表示、編集も同様（メモ帳の基本機能）です。これらの機能が、いついかなる時も不具合なく正常に動作しなければ、はっきり言ってそのエディターは無価値です。
実は、本不具合発生を受けて、サクラエディタ32bit Ver. 2.4.2.6048でも試しましたが、同じような不具合が出て使えませんでした。しかし、サクラエディタは、無料でかつ開発がだいぶ前に停止しているので、まぁ仕方がないかで済みます。
しかし、EmEditorは、永久ライセンスを税抜き21,600円で購入しています（諸般の事情で買いなおしました。それ以前は、会社として購入して４，５年使用していました）。当時、EmEditorの正規表現検索、文字列のソートやBASE64などの変換機能と軽快に動作するのがよかったため、長い付き合いになるだろうと思い、長期使用のコスト削減のため永久ライセンスを買いました。
ところが、2022年の夏あたりにやや複雑な正規表現の検索で突然クラッシュして、編集中のデータをすべて失う惨事に遭い、いろいろ調べてEmEditorの正規表現検索に初歩的な正規表現で不具合があることが分かり、これは他のユーザでもすぐに問題になるだろうからしばらくしたらアップデートが出ると思い、一時的に正規表現検索は別のテキストエディタに切り替えて待っていました。しかし、2022年中にその問題が修正されることはなく、2023年初めにやっと修正されました。そして、そこから正規表現の不具合がいくつか発生して今日に至っています。下記のITreviewのEmEditorレビューコメントは、私も同意するレビューコメントです。
（URLの一つ上の階層のEmEditorには、他の人のコメントも多数あるので、見てないなければ目を通したほうが良いと思います）
https://www.itreview.jp/products/emeditor/reviews/136840このメールを読んで、ご気分が悪くなるでしょうから、返信はなくて問題ありません。
江村様は、開発者のプロですから成果を出すことでこのメールに答えてください。お金をもらって仕事する（サラリーマンでも）のがプロであり、その世界ではお金を出している側にメリットが出るような仕事をするのが当たり前です。それができている前提であれば、＋αで何しても何も言いません。ここから、不具合の詳細になります。
○新規不具合報告（２件）
対象：
EmEditor Professional (64-bit) Version 22.5.2 EmEditor Professional (64-bit) Version 22.9.910正規表現不具合１：
改行のないテキストファイル（数百キロバイト規模）で任意を含む正規表現で前後検索を繰り返すとメインウィンドウがほとんど操作不能になる（応答が著しく遅い）または応答なしになる
正規表現不具合２：
改行のないテキストファイル（数百キロバイト規模）で任意を含む正規表現で検索すると本来は一致しない文字列にも一致する。緑色マークは正しい文字列をマークしているが、検索選択される文字列はマーク済み以外も検索選択する【再現手順】
１．下記のファイルを開く
下記のファイルをそれぞれ開く。
この手順において、問題が発生するのは、(File.A)のファイル。
ファイルは、添付しましたが念のため入手元URLを記載します。
==> 再現手順のJSファイル1114.zip(File.A) 00a21fae68cedf13a0c6.5898.js
DL元：https://abema.tv/assets/modern-desktop/00a21fae68cedf13a0c6.5898.js
DL元(再現確認済み2024/01/16)：https://web.archive.org/web/20240115174131/https://abema.tv/assets/modern-desktop/00a21fae68cedf13a0c6.5898.js２．表示の設定を変更
下記のいずれかで、表示方法をウィンドウの右端で折り返しに設定する
「表示->ウィンドウの右端で折り返し」をクリック
または、
「Ctrl+3」を押下３．検索を開いて、下記の通り設定する
「検索」の設定：
〔チェックボックス〕設定
大文字と小文字を区別する(C)：チェックあり
上記以外のチェックボックスすべて：チェックなし
〔ラジオボタン〕選択
正規表現(X)：チェックあり〔検索->高度〕設定
〔チェックボックス〕設定
チェックボックスすべて：チェックなし
正規表現エンジン(G)：既定(Boost.Regex)
正規表現で検索する追加行数(L)：0４．文字列検索を実行する
次の文字列をそれぞれ入力する。検索文字列
(F1)
&&(?=.*function).+?&&
(F2)
&&(?!.*function).+?&&
(F3)
&(?!.*function).+?&
(F4)
&&(?=.*return ).+?&&
(F5)
&(?=.*return ).+?&
(F6)
&&(?!.*return ).+?&&
(F7)
&(?!.*return ).+?&
(F8)
&&.+?&&「次を検索(N)」または、「前を検索(P)」を数回続けてクリックする。
マウスホイールカーソルまたは、メインウィンドウのスクロースバーで、半分以上のスクロールを行う。５．検索結果
検索文字列(F1)-(F7)は、正規表現不具合１と正規表現不具合２が発生する。
ただし、(F5)は重症になりやすい。(F6),(F7)では、発生率が他より低い。
しばらく待っていると正常な応答速度に戻るが、その後に著しい応答遅延に戻る。ほぼ操作不能で、隙をついてウィンドウの右上×ボタンをクリックして当該プログラムを終了するか、１０分以上待つ以外に回復しない。検索文字列(F8)は、正規表現不具合２が発生する。
2023/11/08(JST)に報告した同種の正規表現の不具合が、修正されたはずのVersion 22.9.910においても発生する。
（正規表現不具合１：改行のないテキストファイル（数百キロバイト規模）で任意を含む正規表現で前を検索を繰り返すと応答なしになる）
明らかに根本的な不具合の修正ができていない。この不具合について、メールでは何ら回答いただいておりません。
Ｑ１．このメールによる不具合報告を読まれた時点でどのように対応する方針だったのでしょうか？Ｑ２．この不具合については現時点までにどのような対応をしてきたのでしょうか？
上記の２点について、それぞれ回答をいただけますでしょうか。
いつもお世話になっております。江村です。
ご迷惑をおかけして申し訳ありません。yasuji 様には、いつも貴重なご意見と不具合報告をいただいており、大変感謝しております。
今回の 2023/11/14 に報告していただいたメールですが、残念ながら、私のところには、届いておりません。私が使用しているメール ソフト (Outlook) の中のすべてのフォルダを yasuji 様のメール アドレスで検索しましたが、届いていませんでした。本メールに .js (JavaScript) のファイルを添付されていたそうですが、おそらく、それが原因で、メール ソフト、あるいはメール サーバー側で、ブロックされてしまったのではないかと思います。参考までに Outlook でブロックされる添付ファイルの種類については、こちらをご参照ください。
今後、メールをお送りいただいたにもかかわらず、もし長らく回答をお待たせしている場合には、再度、添付ファイル無しでお送りいただければ幸いです。
本メールのご質問については、今からすぐにお調べいたします。何かわかりましたら、またここに回答を追加いたします。
今後もよろしくお願いいたします。
いつもお世話になっております。江村です。
問題が再現しましたので、さきほど公開した v23.0.910 で修正しました。
https://jp.emeditor.com/forums/topic/emeditor-v23-1-preview-23-0-901/
原因は、正規表現を使用する [前を検索] が遅くなっていたためです。Boost の Regex は、[前を検索] には対応していません。そのため、アプリ側で追加の処理が必要になるのですが、正確な検索を行おうとすると、前から後方向に検索する必要が生じる場合があり、そのため、1行が非常に長い今回のようなサンプルだと、遅くなっていました。最新版 v23.0.910 では、アルゴリズムの最適化により、[前を検索] も高速化しました。なお、Notepad++ では、正規表現を使用した [前を検索] はサポートされていないため、EmEditor と同列には比較できないと思います。なお、Onigmo の Regex では、[前を検索] には対応されているため、アプリ側で特に追加の処理は必要なく、高速に動作します。
他にも何かお気付きの点がございましたら、ご連絡ください。
今後もよろしくお願いいたします。
いつもお世話になっております。
yasujiです。私のメールソフトでは、送信済みフォルダに残っており、送信できて届いているものと思っておりました。江村様が受信できなかったということは、途中経路のどこかでメールが消失するトラブルがあったんだと思います。たしか過去、私の知人にも複数人に同報で送ったはずのメールが、その時に限ってそのうちの一人だけなぜか届かなかったことがあったそうで、今回は不運にもまれなメールトラブルに遭遇して、双方ともに気づくことは困難な状況でしたので、メール報告していたにもかかわらず何ら対応していなかったのは、メールトラブルが原因ということで水に流します。
したがって、本件の不具合については、今回初めてフォーラムで正規表現の不具合を報告したこととします。すでに、次のご連絡があり、重複しますが、不具合修正をお願いします。
返信先: 新規の正規表現の不具合２件（22.9.910においても発生）#31392に返信
迅速なご対応ありがとうございます。
yasujiです。確認の回答が遅くなり申し訳ありません。不具合を確実に解消していく姿勢と誠意を感じましたため、私のほうもいろいろと言った手前、誠意でお返しするために昨日の夜から私の使える時間でテスト確認をしておりましたが、一旦切り上げて、本日使える時間で残りをテストしました。
一点お願いなのですが、スピードを最優先されたためと十分理解をしておりますが、この記事の中のユニークな「正規表現不具合１」「正規表現不具合２」と簡易IDのような名称を付けておりますので、その名称を明示いただいて、修正完了、未着手、一部修正完了（残りはこれとこれ）などステータスを記載いただけるとどの不具合を確認したらよいかわかりやすく助かります。釈迦に説法とは思いますが、私の説明ではうまくできていないと思いますので、下記のようなものがご参考にいただければ幸いです。
完璧に理解できないバグ票について
テスト計画・不具合やバグの管理には不具合やバグの状態の定義が重要
バグはここに潜んでいる！ 効率よくテストを行うためには？何かお役に立つかもしれないと思い、私の過去の些細な経験からですが、重要と思われるポイントを書かせていただきます。
不具合（バグ）を作りこまない、またテストで発見するためにも設計時の仕様書に、一例として入力値の取りうる範囲（文字列、整数値、小数（小数部の桁数、桁数を超えた場合は切り上げか切り捨てか、四捨五入か、丸め誤差、情報落ち、桁落ち）、bool値）や、関数引数の正常値定義、それ以外の値の場合の関数内エラー処理（エラー値の返却か、例外発生か）を決めてあるかが重要です。
ご参考まで：
テストの抜け漏れが原因で炎上してしまったプロジェクト 手戻りリスクで現場が疲弊しないための3つのポイントスレッドを使用している場合は、スレッド内でのスレッドセーフな関数使用の確認と対策、例外発生のリスク確認と対策（あれば例外キャッチを組み込む、不明な場合もすべての例外を受け取れる例外キャッチを組み込む）で、スレッドが１００％安全終了するようにする。さらに、メインスレッドと並行処理用スレッド、並行処理用スレッド同士で変数の共用の場合は、変数アクセスロック機構が組み込まれているか、スレッドセーフなキュー、スタックを使用しているかもかなり重要です（実装者が、取り合えずスレッドアンセーフの安直な方法で実装して後で修正するつもりが、そのままでバグになるパターンがあります、条件よって確率的にクラッシュすることがある）。
通常のデバッグでは、ブレークポイントで２つ以上のスレッドを同時に止められないので、すべてのスレッド内の挙動の要所の関数呼び出しと、呼び出されたスレッド関数自体の引数パラメータ、戻り値をログ出力して、プログラム終了後に動作検証をしておくことが問題の早期発見に肝要です。
また、ログ出力のフォーマットは、出力日時（ただし、C/C++は処理速度が高速のため、ミリ秒ではなく、マイクロ秒までの記録が必要。できるだけ正確に動作タイミング知るため）、スレッド名称やID（メインスレッド、並行処理用スレッドなどを確実に識別するため）が少なくとも必要です。並行処理用スレッドについては、いつ・どういうパラメータで起動させたか、いつ・どういう戻り値で終了したかのログ記録も必要になります。ログ出力のファイル名には、８桁年月日と６桁時分秒を含めて、プログラム実行時に毎回新規で作成すると実行履歴の保管に役立ちます。スレッド内で何が起きているか、想定通り動作しているかを検証する方法はこれ以外にないと思います。注意点として、あれこれログ出力してデバック実行繰り返していると、不可解なエラーや例外発生が起き始めて、原因探しをしてもよくわからず、ログを見ようとしたらログ出力先のディスクの空き容量がいつの間にか０バイトでログ書き込みエラーが原因だったという笑えない話もあります。迅速な不具合修正対応ができているので、出過ぎたことをしたかもしれませんが、過去のバグの内容や今回のテストでの動作から想起した内容で気になりましたので書かせていただいた次第です。当たり前だと思われたらお読み捨ていただいて構いません。
前話が長くなり申し訳ありません。
v23.0.910の不具合修正確認をいたしました。いくつか試したところ不具合がまだ完全に修正されていないようでしたので、少し正確にテスト結果が分かるようにまとて、テストシナリオにも不具合が定量的にわかるように手を加えました。江村様の迅速な対応と誠意にお応えするためと、どうしても修正してスマートに操作できるテキストエディターに仕上げていただきたく、こちらも誠意としてできる限りのことをさせていただきました。この不具合について、メールトラブルがあったとはいえ、怒りで一方的に攻め立ててしまいましたので、その代償として詳細なテスト結果報告を記載しました。
申し訳ないのですが、このような詳細な報告は、今回限りとさせてください。次回以降は、あまり手間をかけずに済む簡便な文章での報告とさせてください。以下は、詳細なテスト結果報告になります。最終結果は最後に記載しました。
全般的に、正規表現検索をせずにファイルを開いただけの操作性や応答状態を基準にすると、正規表現検索を一度でも実行するとメインウィンドウの動作が、一時的に短時間応答しなくなる、操作がカタつく現象が発生します。
==============================
テスト対象：
v23.0.910修正確認対象不具合：
正規表現不具合１改修前の発生不具合現象：
(a1)メインウィンドウがほとんど操作不能になる
(a2)メインウィンドウが応答が著しく遅い
(a3)メインウィンドウが応答なしになるテストの実施手順概要：
テスト実施は、テストシナリオと検索文字列の組み合わせごとに、対象プログラムを起動させて、「テスト前事前準備」を実行した後に、テストシナリオを実施して、その完了後に対象プログラムを終了させる。検索文字列：
(F1)
&&(?=.*function).+?&&
(F2)
&&(?!.*function).+?&&
(F3)
&(?!.*function).+?&
(F4)
&&(?=.*return ).+?&&
(F5)
&(?=.*return ).+?&
(F6)
&&(?!.*return ).+?&&
(F7)
&(?!.*return ).+?&
(F8)
&&.+?&&テスト前事前準備：
１．下記のファイルを開く
下記のファイルをそれぞれ開く。
この手順において、問題が発生するのは、(File.A)のファイル。
ファイルは、添付しましたが念のため入手元URLを記載します。
==> 再現手順のJSファイル1114.zip(File.A) 00a21fae68cedf13a0c6.5898.js
DL元：https://abema.tv/assets/modern-desktop/00a21fae68cedf13a0c6.5898.js
DL元(再現確認済み2024/01/16)：https://web.archive.org/web/20240115174131/https://abema.tv/assets/modern-desktop/00a21fae68cedf13a0c6.5898.js２．表示の設定を変更
下記のいずれかで、表示方法をウィンドウの右端で折り返しに設定する
「表示->ウィンドウの右端で折り返し」をクリック
または、
「Ctrl+3」を押下３．検索を開いて、下記の通り設定する
「検索」の設定：
〔チェックボックス〕設定
大文字と小文字を区別する(C)：チェックあり
上記以外のチェックボックスすべて：チェックなし
〔ラジオボタン〕選択
正規表現(X)：チェックあり〔検索->高度〕設定
〔チェックボックス〕設定
チェックボックスすべて：チェックなし
正規表現エンジン(G)：既定(Boost.Regex)
正規表現で検索する追加行数(L)：0テストシナリオと検索文字列ごとの結果：
(T-1.1)「次を検索(N)」を数回続けてクリックする。
マウスホイールカーソルで、半分以上（１０回転を１セット）のスクロールを行う。
(F1)マウスホイールカーソルで下へスクロール操作後、1秒から2秒程度の遅延してスクロールするが、数行程度スクロールすのみで回転数に対して圧倒的に少ない。マウス操作直後からUI全体が0.5秒から2秒程度応答しなくなって回復する。
(F2)マウスホイールカーソルで下へスクロール操作後、1秒から3秒程度の遅延してスクロールするが、数行程度スクロールすのみで回転数に対して圧倒的に少ない。マウス操作直後からUI全体が0.5秒から2秒程度応答しなくなって回復する。
(F3)(F2)に同じ。
(F4)マウスホイールカーソルで下へスクロール操作後、1秒から2秒程度の遅延してスクロールするが、数行程度スクロールすのみで回転数に対して圧倒的に少ない。
(F5)(F4)に同じ。
(F6)(F2)に同じ。ただし、UI全体でなく検索ウィンドウ。
(F7)(F2)に同じ。
(F8)一度も遅延せずスムーズにスクロール操作できる。(T-1.2)「次を検索(N)」を数回続けてクリックする。
メインウィンドウのスクロースバーで、半分以上のスクロールを行う。
(F1)スクロールは、マウスカーソル移動後に0.5秒から2秒程度の遅延してスクロールが追いつく。時間が経過すると、スムーズにスクロール操作できるようになる。
(F2)スクロールは、マウスカーソル移動後に2秒から3秒程度の遅延してスクロールが追いつく。時間が経過すると、スムーズにスクロール操作できるようになる。
(F3)(F2)に同じ。
(F4)(F1)に同じ。
(F5)(F2)に同じ。
(F6)(F2)に同じ。
(F7)(F2)に同じ。
(F8)一度も遅延せずスムーズにスクロール操作できる。(T-1.3)「次を検索(N)」を数回続けてクリックする。
メインウィンドウのテキストについて、マウスで２０文字以上を文字列選択を異なるで箇所で連続的に１０回行う。
(F1)マウス選択操作をした後、背景色青色選択表示になるまで0.5秒から3秒程度の遅延が生じる。生じる遅延時間に規則性はなし。
(F2)「次を検索(N)」を押下後の「見つかりませんでした」のメッセージ表示まで、2秒から3秒ほど(F8)より遅い。(F1)に同じ。
(F3)「次を検索(N)」を押下後の「見つかりませんでした」のメッセージ表示まで、2秒から3秒ほど(F8)より遅い。(F1)に同じ。
(F4)(F1)に同じ。
(F5)(F1)に同じ。
(F6)「次を検索(N)」を押下後の「見つかりませんでした」のメッセージ表示まで、2秒から3秒ほど(F8)より遅い。(F1)に同じ。
(F7)「次を検索(N)」を押下後の「見つかりませんでした」のメッセージ表示まで、2秒から3秒ほど(F8)より遅い。(F1)に同じ。
(F8)マウス選択操作をした後、マウスカーソルに追従して背景色青色選択表示になる。一度も遅延せずスムーズ。(T-2.1)「前を検索(P)」を数回続けてクリックする。
マウスホイールカーソルで、半分以上（１０回転を１セット）のスクロールを行う。
(F1)マウスホイールカーソルで下へスクロール操作後、1秒から2秒程度の遅延してスクロールするが、数行程度スクロールすのみで回転数に対して圧倒的に少ない。マウス操作直後からUI全体が0.5秒から2秒程度応答しなくなって回復する。
(F2)(F1)に同じ。
(F3)(F1)に同じ。
(F4)(F1)に同じ。ただし、UI全体の応答しないは、マウス操作の３セットに一度程度で、0.5秒から1秒程度。
(F5)(F1)に同じ。
(F6)(F1)に同じ。
(F7)(F1)に同じ。
(F8)一度も遅延せずスムーズにスクロール操作できる。(T-2.2)「前を検索(P)」を数回続けてクリックする。
メインウィンドウのスクロースバーで、半分以上のスクロールを行う。
(F1)スクロールは、マウスカーソル移動後に0.5秒から2秒程度の遅延してスクロールが追いつく。時間が経過すると、スムーズにスクロール操作できるようになる。
(F2)スクロールは、マウスカーソル移動後に2秒から3秒程度の遅延してスクロールが追いつく。時間が経過すると、スムーズにスクロール操作できるようになる。
(F3)(F2)に同じ。
(F4)(F1)に同じ。
(F5)(F1)に同じ。
(F6)(F2)に同じ。
(F7)(F2)に同じ。
(F8)一度も遅延せずスムーズにスクロール操作できる。(T-2.3)「前を検索(P)」を数回続けてクリックする。
メインウィンドウのテキストについて、マウスで２０文字以上を文字列選択を異なるで箇所で連続的に１０回行う。
(F1)マウス選択操作をした後、背景色青色選択表示になるまで0.5秒から3秒程度の遅延が生じる。生じる遅延時間に規則性はなし。
(F2)(F1)に同じ。
(F3)(F1)に同じ。
(F4)マウス選択操作をした後、背景色青色選択表示になるまで0.0秒から1秒程度の遅延が生じる。生じる遅延時間に規則性はなし。
(F5)(F1)に同じ。
(F6)(F1)に同じ。
(F7)(F1)に同じ。
(F8)マウス選択操作をした後、マウスカーソルに追従して背景色青色選択表示になる。一度も遅延せずスムーズ。最終結果：
確認した結果、下記の通りの不具合の発生と解消を確認しました。
発生不具合：
(a1)メインウィンドウがほとんど操作不能になる（短時間で一時的）、(a2)メインウィンドウが応答が著しく遅い
解消不具合：
(a3)メインウィンドウが応答なしになる
==============================いつもお世話になっております。江村です。
本件は、検索文字列の強調表示 (正規表現にマッチする文字列が黄緑色に表示されるもの) が有効になっている場合に、発生する問題だと考えられます。既定では、有効になっていますが、これを無効にするためには、設定のプロパティの [表示] ページで、[検索色] に 0 を指定してください。
しかし、これが有効の場合でも、もっと速く動作するようにならないか最適化してみます。また何かわかりましたら、ここに回答を追加します。
よろしくお願いいたします。
v23.0.912にて、「正規表現不具合１」は改善されたと感じます。
ところで、「正規表現不具合２」についてですが、下記の説明の意味が分かりません。
>本件は、検索文字列の強調表示 (正規表現にマッチする文字列が黄緑色に表示されるもの) が有効になっている場合に、発生する問題だと考えられます。既定では、有効になっていますが、これを無効にするためには、設定のプロパティの [表示] ページで、[検索色] に 0 を指定してください。
示された設定箇所は、そこにたどり着くためのUI操作パスが示されていなく、どうやって設定したらいいかわかりません。
そもそも、江村様は、「正規表現不具合２」の不具合内容と、EmEditorの仕様とソースコードの実装仕様を理解しているとは思えない回答の仕方をしています。
つまり、EmEditorの開発エンジニアおよび江村様の実力がほとんどないため、この不具合を解消することができません。したがって、検索文字列の強調表示をしないようにして、誤魔化してお使いくださいということでよろしいでしょうか？はっきり言って、「私どものEmEditorのできがかなり悪くポンコツのために、お客様のほうで不便になるよう設定を変えてポンコツなEmEditorをお使いください」という理解いたしました。
これ以外に、理解の仕様がない回答です。いつもお世話になっております。江村です。
「正規表現不具合２」の以下の内容については、見落としておりました。回答が遅くなり申し訳ありません。
改行のないテキストファイル（数百キロバイト規模）で任意を含む正規表現で検索すると本来は一致しない文字列にも一致する。緑色マークは正しい文字列をマークしているが、検索選択される文字列はマーク済み以外も検索選択する
これについて回答させていただきます。検索により一致した文字列と、強調表示により一致する文字列とは、必ずしも一致しません。強調表示は、[置換] ダイアログで、[すべて置換] を選択して全置換と動作が似ています。
これを簡単な例で説明しますと、次のようになります。例えば、
AAAAAという文書があったとします。そこで、
AAを検索します。すると、最初の４文字の
AAAAだけが強調表示されますが、[次を検索] (F3) コマンドを実行すると、1個ずつ検索位置がずれて表示されるため、最後のAAまですべて検索することができます。本件のサンプルと正規表現においても、同様に、強調表示されていない部分に検索結果が一致することもありますが、特に不具合は確認できませんでした。
また、設定のプロパティの [表示] ページに行くには、[ツール] メニューで、[現在の設定のプロパティ] または [すべての設定のプロパティ] を選択してください
よろしくお願いいたします。
「正規表現不具合２」の回答について確認いたしました。
検索の動作について、私が考えていた動作と完全に乖離していました。
さきほど、v23.0.914を使用して、私の提示したファイルはJavaScriptで複雑なため、簡単なテキストを作成して動作確認をしたところ、江村様のご説明の通りの検索挙動になっていることを確認しました。私の考えていた検索の挙動は、下記のような条件を用意した場合、[次を検索] (F3) を押下すると、１回目は先頭から１文字目からのAAを選択、２回目は先頭から３文字目からのAAを選択、これ以上選択できるものがないため検索が終了する（一致する文字列はもうないというメッセージが表示される）というものでした。
検索ウィンドウオプション：
「正規表現(X)」または「(無し)(O)」
テキスト文書上のカーソル位置：文書の最先頭
検索文字列：
AA
テキスト文書：
AAAAAEmEditorの検索においては、上記の条件を用意した場合、[次を検索] (F3) を押下すると、１回目は先頭から１文字目からのAAを選択、２回目は先頭から２文字目からのAAを選択、３回目は先頭から３文字目からのAAを選択、４回目は先頭から４文字目からのAAを選択、これ以上選択できるものがないため検索が終了する（一致する文字列はもうないというメッセージが表示される）という動作になっている。
私の理解が正しくできているかの確認ですが、江村様が説明された検索の挙動については、上記の「EmEditorの検索においては」で説明した挙動で一致していますでしょうか？
検索の動作について、私が江村様の検索の動作の理解を正しくできたとすると（一つ上の確認質問の回答がはいの場合）、検索の動作はEmEditorの仕様通りの動作であり、何ら不具合はないという説明で理解と納得ができますので、「正規表現不具合２」についての報告は取り下げさせていただきます。
そのような検索挙動だとは、まったくわかっておらず不具合と騒ぎ立てて申し訳ありませんでした。この検索の動作について、理解を深めるためにいくつか教えていただけないでしょうか。
（１）この検索の動作仕様は、何かメリットがあって実装されたのか、または何か当時課題があってその課題を解決するために実装されたのでしょうか？
（２）この検索の動作仕様は（不具合などは抜きで）、EmEditorのどのバージョンから実装されたのか？または初期から搭載されていたのか教えていただけないでしょうか？
（３）検索の動作仕様については、オンラインヘルプ等などに記載されている箇所を教えていただけないでしょうか？または常識の動作のため記載がなくても実用上差しさわりがないということも考えられます（検索についての正規表現関係は見ていたのですがそのような記載はなかったように記憶しているため、再度不具合として報告があるとお手間が増えると思ったため）。よろしくお願いします。
いつもお世話になっております。江村です。
EmEditorの検索においては、上記の条件を用意した場合、[次を検索] (F3) を押下すると、１回目は先頭から１文字目からのAAを選択、２回目は先頭から２文字目からのAAを選択、３回目は先頭から３文字目からのAAを選択、４回目は先頭から４文字目からのAAを選択、これ以上選択できるものがないため検索が終了する（一致する文字列はもうないというメッセージが表示される）という動作になっている。
それで正しいです。
（１）この検索の動作仕様は、何かメリットがあって実装されたのか、または何か当時課題があってその課題を解決するために実装されたのでしょうか？
この動作が通常の動作であり、他の動作は思い付きませんでした。
（２）この検索の動作仕様は（不具合などは抜きで）、EmEditorのどのバージョンから実装されたのか？または初期から搭載されていたのか教えていただけないでしょうか？
初期からです。
（３）検索の動作仕様については、オンラインヘルプ等などに記載されている箇所を教えていただけないでしょうか？または常識の動作のため記載がなくても実用上差しさわりがないということも考えられます。
特に記載されていません。しかしながら、私の知る限り、ほとんどのテキスト エディターは EmEditor と同様の動作をするはずです。その理由ですが、検索の際には、考えられるすべての一致を検索するべきだからではないでしょうか? そうでないと、重要な検索一致箇所を見逃す可能性があります。例えば、
&A&B&C&という文書があったとします。そこで、
&.&という正規表現を検索したいとします。
yasuji 様のお考えの動作 (強調表示や、[すべて置換] と同様な検索) だと、
&A&が一致した直後に、[次を検索] (F3) コマンドを実行すると、
&C&が一致します。
しかし、ユーザーは
&A&と&C&の間にある&B&も一致されることを期待するはずです。&A&、&B&、&C&の 3箇所の重要性は同じだと考えられます。そこで、[次を検索] コマンドでは、できるだけ多くの可能性を見逃さずに一致させることを意識しています。
しかしながら、yasuji 様のお考えの動作を希望される場合には、オプションの追加も検討いたしますので、再度、その理由も含めてご連絡ください。
よろしくお願いいたします。
丁寧なご回答ありがとうございます。
（１）～（３）までのご回答で、EmEditorにおいての検索機能の本質を理解することができました。正直申し上げますが、#31408の江村様のご回答を初めて読んだとき、説明していることがまったく理解できませんでした。もう一度読み直して、一行ずつ文章の意味を慎重に理解して、最後の行まで理解したときに、頭が野球用の木製のバットで叩かれたような強い衝撃が走りました。別な言い方をすれば、ビルのオープンな１階フロアに入ろうとしたら、綺麗に磨かれたガラスの壁にまったく気づかずに頭をぶつけた時のような衝撃です。
回答いただいた（３）に書かれたEmEditorの検索動作（アルゴリズム）について、通常のエンジニアの認識と、私の動作希望について書かせていただきます。
（３）で江村様の検索の動作の考え方ならびにEmEditorの検索の動作（アルゴリズム）は、世界（グローバル）のどの情報技術に関係するエンジニアの１００％がおかしい挙動をしていると認識します。
私は１０年以上情報技術のエンジニアをしてきました。OSは、Ubuntu, Redhat, CentOS, Windowsなどを扱ってきました。テキストファイル内の文字列検索をする場合は、コマンドを使うか、テキストエディタを使うことになります。例えば、Linux OSであれば、sed, grep, egrepが有名な正規表現に対応したコマンドになります。Windows 10であれば、findstrコマンドになると思います。テキストエディタだと、LinuxOSではシェル上で動作するemacs, nano, vimあたりが有名でよく使われます。Windowsだと、Emeditor以外ですと、Sakura Editor, 秀丸エディタ, Notepad++などフリーを交えて有名どころで使われています。ただし、個人的によく知っている範囲です。これらのコマンドやテキストエディタを状況に応じて使ってきました。しかし、どのコマンドやどのテキストエディタにおいても、（３）の検索アルゴリズムで動作するものは一つもありません。
「エンジニアの１００％がおかしい挙動をしていると認識します。」と断言できたのは、世界中で使われているLinux OSに搭載されているテキストファイルの文字列検索コマンドが（３）の検索アルゴリズムではなく、私が認識している検索アルゴリズムを採用していて、世界中のエンジニアの間では常識になって言います。したがって、仮にそれらのコマンドのいずれかに（３）のアルゴリズムを検索機能として実装したとすると、確実にユーザからバグとして報告され他のエンジニアによって修正されます。江村様は、どうも検索の機能の本質を理解されていないようです。検索機能は、検索対象のテキスト文書の中で検索文字列が重複なくどこに何個出現しているかを特定する機能です。江村様の考えた検索機能は、検索機能の必須条件を満たしていません。ちなみに、江村様が個人の範囲で使うのもインターネットを使ってその考え方を発信するのも自由です。
しかし、無料／有料問わずテキストエディタとして、文字列の検索機能を提供する場合は、まずは他のテキストエディタでは、検索機能のアルゴリズムはどうなっているかをよく調べて、自身の検索アルゴリズムの違いはあるか、あるとそればどこになるかを明らかにして、ヘルプやテキストエディタの機能の説明欄などに明確に動作を説明するべきです。
私なりに、わかりやすく順序だてて説明したつもりです。
シンプルに言えば、EmEditorの検索機能のアルゴリズムが世界中で使われているテキストエディタと文字列検索コマンドにおいて検索機能のアルゴリズムが全く異なります。（３）のような考え方のアルゴリズムで検索機能を実現しているのは、EmEditorただ一つのみです。江村様の次の説明が非常に気になりました。
しかしながら、私の知る限り、ほとんどのテキスト エディターは EmEditor と同様の動作をするはずです。
「～はずです」という言葉を使うときは、私の経験上間違いなく、現実の現物を一切確認しないあるいは中身を確認せずに表面だけ確認して、机上の空論で自分が正しいという場合に使われます。
なぜ、このようなことが言えるのかというと、過去において組織の中で、「～は書類に書いてあるはず」「～はだれだれがやったはず」などいう人が多くいました。役職なしの社員だったので、安心して実際に確認すると、書類には書いていなかった、それどころか書類が作られていなかった、誰もやっていなかったということしかなく、結局自分がそれらの後始末せざるを得ない状況に追い込まれた経験が山ほどあるためです。こういう経験を何回かしてからは、「～はずです」という説明自体を信じないで具体的に確認するようになりました。また、そのような言葉遣いをするいかなる人も信用することはありません。理由は、「～はず」の説明を信じて行動したら、説明されたことができていなく、それを自分の責任にされるという裏切りを何度か経験したため。こういうことをする人に限って、ごまかしたりだましたりする説明が全員なぜか上手でした。しかしながら、私の質問に対して、正面から正々堂々と一つ一つ丁寧に回答いただき、誠意を感じましたので、余計なことかもしれませんが、世界の「検索」のデファクトスタンダードとなっているアルゴリズムについて説明させていただきました。
世界中で実装されている共通の検索アルゴリズムの考え方を前提に下記についても、気になったので私の考えを書かせていただきます。
その理由ですが、検索の際には、考えられるすべての一致を検索するべきだからではないでしょうか? そうでないと、重要な検索一致箇所を見逃す可能性があります。
しかし、ユーザーは &A& と &C& の間にある &B& も一致されることを期待するはずです。&A&、&B&、&C& の 3箇所の重要性は同じだと考えられます。
そこで、[次を検索] コマンドでは、できるだけ多くの可能性を見逃さずに一致させることを意識しています。
上記の２つの引用で示した江村様の考え方は、「検索」（検索文字列の出現箇所を重複なく特定することが主目的）ではありません。パターンの出現箇所を一部重複を許容して特定することが主目的になりますので、造語になりますが、「パターン検索」、「パターン置換」が機能名として正しいです（機能の目的または効果を直感的に理解できる機能名であることが重要です）。
検索機能では、検索する文字列の一部が重なるような出現を許容しないためです。しかし、上記のような機能も昨今のAIブームでパターン認識のやり方や見つけ方が重要になってきていますので、もしかするとニーズがあるかもしれません。
パターン検索という機能であれば、検索文字列をパターンとして考えて、検索文字列の一部が重なることを許容することが必要になるためです。AIともてはやされてはいますが、使われている技術としては深層学習（Deep Learning）を基本にして、ニューラルネットワーク構造の工夫と扱えるパラメータ数を飛躍的に向上させて、質問理解（現時点では正確には統計的な理解と思っています）とその最適と推定される回答を学習したデータから生成することができるようになり、昨今あちこちで実装されてサービス提供がされるようになったのがざっくりとした私の認識です。
このAIに関しては、最初は画像が主だったのですが、昨今はテキストを扱えるようになり、パターン認識というのがキーワードとしてあちこちに登場するので、ひょっとしたらと考えた次第です。
私も、この分野には明るくはないのですが、AIに参戦して開発をしているのが、Google、マイクロソフト、メタなどいわゆるビックテック企業とベンチャー系企業で、どうなっているかたまにIT系ニュースで見ていますが、雨後の筍のようにサービスが立ち上がったり、新しいAIが出てきたり、古いタイプのAIがいつの間にかなくなっていたりしながら、企業同士の混戦模様に見えています。したがって、どなたかのユーザさんがAIの機能やらマクロやらを作ってほしいという要望があるようですが、それらは使いたい本人が詳しいでしょうからご自身でマクロを作るなり、市販のAIツールなどを使うなどの元来エンジニアがするべき工夫してうまく使いこなしていくもらうことで問題ないですし、私の提案した機能についても一旦EmEditorの機能からは取り外して、今は動向をウォッチしながら静観して、必要に応じて再調査と再検討をされるのがよろしいと思います。
しかしながら、yasuji 様のお考えの動作を希望される場合には、オプションの追加も検討いたしますので、再度、その理由も含めてご連絡ください。
それでしたら、私が説明した検索のアルゴリズム（動作）を現時点での検索機能と別で新検索置換機能として搭載していただきたので、具体的な希望とその理由を別トピックを作成してご連絡させていただきます。
江村様
yasujiです。
いつもお世話になっております。江村です。
少なくとも Visual Studio では、EmEditor と同様の動作をします。
何が言いたいのか、まったくわからないのですが。
その回答内容は、 新規の正規表現の不具合２件（22.9.910においても発生） – #31412で、書いておくことができますよね？なぜ、ここまで私に言わせてから上記の回答内容なのでしょうか？
引用元： 新規の正規表現の不具合２件（22.9.910においても発生） – #31419
江村様は、どうも検索の機能の本質を理解されていないようです。検索機能は、検索対象のテキスト文書の中で検索文字列が重複なくどこに何個出現しているかを特定する機能です。江村様の考えた検索機能は、検索機能の必須条件を満たしていません。ちなみに、江村様が個人の範囲で使うのもインターネットを使ってその考え方を発信するのも自由です。
しかし、無料／有料問わずテキストエディタとして、文字列の検索機能を提供する場合は、まずは他のテキストエディタでは、検索機能のアルゴリズムはどうなっているかをよく調べて、自身の検索アルゴリズムの違いはあるか、あるとそればどこになるかを明らかにして、ヘルプやテキストエディタの機能の説明欄などに明確に動作を説明するべきです。
私なりに、わかりやすく順序だてて説明したつもりです。「～はずです」という言葉を使うときは、私の経験上間違いなく、現実の現物を一切確認しないあるいは中身を確認せずに表面だけ確認して、机上の空論で自分が正しいという場合に使われます。
なぜ、このようなことが言えるのかというと、過去において組織の中で、「～は書類に書いてあるはず」「～はだれだれがやったはず」などいう人が多くいました。役職なしの社員だったので、安心して実際に確認すると、書類には書いていなかった、それどころか書類が作られていなかった、誰もやっていなかったということしかなく、結局自分がそれらの後始末せざるを得ない状況に追い込まれた経験が山ほどあるためです。こういう経験を何回かしてからは、「～はずです」という説明自体を信じないで具体的に確認するようになりました。また、そのような言葉遣いをするいかなる人も信用することはありません。理由は、「～はず」の説明を信じて行動したら、説明されたことができていなく、それを自分の責任にされるという裏切りを何度か経験したため。こういうことをする人に限って、ごまかしたりだましたりする説明が全員なぜか上手でした。上記のことを言われて、腹が立ったからVisual Studioと同じという説明で切り捨てたのですか？
対応が最低ですね。
実は、Visual Studioはインストール済みでして、確認したら確かにEmEditorと全く同じ検索挙動で腰抜かすほど驚きましたよ。
マイクロソフトという会社が一体何やってんの？というのが正直な感想です。昔はこんなことする会社ではなかったんですが。。。私は、小学生が答えられるような回答は求めていません。検索動作の考え方が、まったく違うことについて、どう考えているのですか？
しっかり回答してください。以上
- このトピックに返信するにはログインしてください。