フォーラムの返信を作成しました。
- 投稿
江村様
お世話になっております。
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.としての江村様のお考えでですので、私としてはこれ以上追及するつもりはありません。さすがに、私も疲れてしまいましたので。いつもお世話になっております。
yasujiです。EmEditor v24.3.903において、不具合の修正結果を確認しましたが、下記の通り修正されたものと、未修正のものがあります。
５．結果の確認
==> 不具合がまだ残っています。手順通りに再現できます。８．結果の確認
==> 修正されて不具合が解消されたことが確認できました。１１．結果の確認
==> 不具合がまだ残っています。手順通りに再現できます。再度、ご確認とご対応をお願いします。
江村様
お世話になっております。
yasujiです。取り急ぎのご回答ありがとうございます。
お忙しい中でちょっとした手違いで情報が出せていなく、そのあとで気づかれたときにブログの内容を更新できるのであれば、そのように対応いただければ問題ありません。
もっと詳細に記載いただけるのであれば、低い発生確率でもわかる範囲で影響を受ける機能名（EmEditor上のGUIのメニュー項目名やボタン名など）、もし明確であれば発生条件（特定の設定値や入力文字列など）を出していただければ大いに助かります。もし、特定の機能によらず内部の処理に関わるのであれば、全般的にかかわる不具合と記載いただければ助かります。こういった情報は、重要度が増しております。Windowsだとアップデートしたら一部の機能が使えなくなったりブートに失敗したり、どことは言いませんがあるベンダーのウイルス対策ソフトをアップデートして再起動したらそれが原因でWindowsが正常に使用できなくなって問題になったりなど不具合を治すはずのアップデートで思わぬトラブルに遭うことがあまり珍しいことではなくなりつあると感じてきています。したがって、どのユーザもほとんど同じだと思いますが、アップデート前にどのような修正が入ったのかをチェックして、どういう不具合が治ったのかや現在の使い方にどういう影響があるかをかなり気にしています。
内容からして軽度な修正と判断できれば、そのままアップデートもありますが、自分に影響がありそうだと判断すればポータブル版でまずいつもの設定をして、いつものテキスト編集作業を一通りやってみて影響がないこともしくは、変更点があったらその変更分の操作方法を考えて、いつもの業務ができることを確認してアップデートをするというのが、当たり前になりつつあります。したがって、修正された不具合の内容の記載がない場合は、自分ですべての利用ケースを確認する必要が生じますがとてもそのような時間が取れないので、よくわからない場合はアップデートせずに現状維持するのがユーザとしてのセオリーになっています（誰一人として地雷は踏みたくないため）。
今後は是非ともお願いいたします。
江村様
お世話になっております。
yasujiです。このまま何もせず具体的な修正内容の情報を得ることができずにこの問い合わせが終了すると思っておりました。
さきほど、更新いただいたv24.3.1 と v24.3.2 のブログのリリース情報を確認しました。
「今回の不具合は非常に軽微なもので、多くのユーザーには影響がないと考えています。」(引用元：#31898 – ここ最近のEmEditorのリリース情報について)ということでしたので、ＵＩの文言修正や表示の不具合を指しているものと考えていました。
ただし、今まで開示していた不具合情報を突然開示しなくなり、かつ私のこの最初の問い合わせについての江村様の初回の回答内容から何か重大な不具合を隠している可能性が高いと予測していました。
つまり、江村様としては、高品質で宣伝しているEmEditorの評判をこれ以上落としたくないが、その評判を落としかねない不具合が見つかってしまった。その不具合の存在をユーザに知られることなく修正してリリースする必要に迫られたので、具体的な不具合情報を書かないで公開したのではないかと強く疑っておりました。私は、ＵＩの文言修正が数件、何か重大な不具合が１件あると予想していましたが、その予想を超えた重大な不具合であるクラッシュバグが２つのバージョンで合計５件あり、かなり強いショックを受けたのが正直な感想です。
発生確率が稀でクラッシュする不具合（３件）とクラッシュする可能性の不具合（２件）が、「今回の不具合は非常に軽微なもので、多くのユーザーには影響がないと考えています。」の不具合として主張していたことに含まれていたことが、とてもとてもショッキングでした。あまりのショックで、気持ち悪くなってしまいレモンティーを作って飲んで気持ちを落ち着かせているほどです。#31907 – ここ最近のEmEditorのリリース情報について
繰り返しますが、決して不具合情報を意図的に隠しているのではありません。
そうでないというのであれば、私が指摘した通りに書けば良いだけです。
したがって、「なぜ書かなかったのか？」に今回の問題の本質があります。- 初回公開されたv24.3.1のリリース情報（2024/08/27時点のweb archive）とv24.3.2のリリース情報（2024/08/27時点のweb archive）に書かなかった
- 私の初回の質問に対して江村様の回答は「今回の不具合は非常に軽微なもので、多くのユーザーには影響がないと考えています。」と主張して書かなかった
この二つの事実から、不具合情報を意図的に隠したとすべてのユーザが１００％判断します（日本語圏や英語圏、他の言語圏すべてです）。
もし、上記の引用の通りであれば、不具合を意図的に隠していないと主張するのではなく、「なぜ以前書いていた不具合情報を書かなかったのか？」の明確な理由を書くべきではないでしょうか？
納得できる理由がなければ、江村様の上記の主張を誰一人として受け入れることはありません。さらに付け加えれば、認識している不具合情報を隠さずすべて、今回提示された情報レベルで開示する行動を継続していただく必要があります。
いつもお世話になっております。
yasujiです。趣旨が違うというほどではないかと思います。単に不具合を連絡する側がわかりやすく内容を書いてほしいという意味で理解していました。したがって、ユーザへ不具合修正等を含むリリース情報を提供する側の江村様も本質的には同じかと思っております。
「お客様により報告された不具合を修正しました。」と書かれただけでは、何もわからず、自分が使っている機能に関係しているのかもわからず、更新は一旦様子を見てという判断になるのが、ユーザの正しい判断になります。ここ最近ですと、CrowdStrikeのアップデートによる大規模障害がよい例です。どのようなソフトウェアやＯＳもアップデートには慎重になるのが、当たり前かと思います。
EmEditorもユーザから見れば日々使うので、インフラと同じになりますので、トラブルは避けたいのがユーザの共通の考えだと思います。なので、不具合の内容がないと、いつも使っている機能や操作の仕方に影響があるのか？と考えて、アップデートは試す余裕がある時まで先延ばしにしようと考えるのではないかと思います。
また、「EmEditor v24.1.1 を公開しました」のリリース情報と比べると、不具合と記載しておきながらその内容が無いに等しいので何かあるのではないかと考えるのは道理だと思います。「不具合は非常に軽微なもの」がそれぞれ少なくとも１件ずつ不具合としてあったのならば、そのように記載すれば良いだけではないでしょうか？
ブログのリリース情報について、確認したいことがあります。
（１）ブログのリリース情報の中で、「お客様により報告された不具合」という表現をした不具合は、すべて非常に軽微な不具合でユーザへの影響はないものと江村様が判断した不具合のことだと理解して良いでしょうか？
今回の質問をさせていただいたのは、不具合の情報を書かなくなった点と、下記の不具合の記載が少なくとも最新とそのひとつ前のリリース情報には記載されておらず、どのバージョンで修正されたのかが認識できなかったためです。
（２）下記の不具合は、最新のリリースの修正に含まれていた不具合で「今回の不具合は非常に軽微なもので、多くのユーザーには影響がない」といえる不具合だったのでしょうか？軽微であってもわざわざ連絡するほどの手間をかけられないだけで、気にされているユーザは意外と多いのではないかと思います。
#31859 – ツールバーに閉じるの段を付けてもらいたいです> それからクリックする度にファイルの表示位置が変わる不具合？みたいな動作があります。
この不具合は最新版で修正されています。お使いの EmEditor のバージョンは、最新版になっていますでしょうか?
上記の返信として書けるのであれば、ブログのリリース情報にその内容を軽微な不具合修正として、書けば良いのではと思った次第です。
さらに言えば、わざわざユーザにこのフォーラムで不具合かもしれないと、質問させるより、それより以前のブログのリリース情報に具体的な不具合内容を書いておけば、ユーザが確認質問する手間は少なくとも省けたと思います。申し訳ありません。私の記載ミスで、２．のテキスト、冒頭と３．正規表現が不具合を正確に表せるものになっておりませんでした。
そのため、正しく説明できる内容に修正しました。
—————————————————–
江村様いつもお世話になっております。
yasujiです。正規表現検索で、使用できる文法がBoost.RegexとOnigmoで一致していない不具合です。
Boost.Regexは「Perl」ですが、Onigmoは「Ruby」のため同じ文法を使用することができません。正規表現の文法の違いがわかる一例としてサブルーティン呼出があります。
Perlでは(?<a>[A-Z])(?&a)、Rubyでは、(?<a>[A-Z])(\g<a>)になり、同じ式を利用できずマニュアルにもどこにも情報がありません。上記不具合の発生の再現手順は下記の通りです。
〔対象〕
v24.3.2 (64bit)〔使用環境〕
OS: Windows 10 Pro 64bit, ver 22H2〔再現手順〕
１．EmEditor 64bit ポータブル版を初期状態で起動
zipファイルから展開して、起動する。
初回のエディション選択は、Professionalを選択する。２．開いている文書タブに適当なテキストの入力
例えば、下記のようなテキストを文書タブに入力して未保存状態にする。"( AAAAAAAAAAAAAAA BBBBBBBBBBBBBB )" CCCCCCCCCCCC DCDCDCDCDCDCDCD ( AAAAAAAAAAAAAAA BABABABABABABA ) "( AAAAAAAAAAAAAAA BBBBBBBBBBBBBB )" -------３．検索を開いて、下記の通り設定する
［検索する文字列］
(?<a>[A-Z])(?&a)〔チェックボックス〕
［一致する文字列を数える(U)］：ON
上記以外のチェックボックスすべて：OFF
〔ラジオボタン〕
［正規表現(X)］：ON［高度］
〔チェックボックス〕
［CRとLFを区別する(T)］：ON
［次を検索/前を検索で重ならない文字列のみ一致する(F)］：ON
上記以外のチェックボックスすべて：OFF
［正規表現エンジン(G)］：Onigmo
［正規表現で検索する追加行数(L)］：0４．[次を検索]を実行する
５．結果の確認
「正規表現には構文エラーが含まれています。」のエラーメッセージボックスが表示されて、実行に失敗する。Onigmoは、SyntaxオプションにPerlがあり本来は使用することができるが、できないEmEditor側が関数呼出時に文法を指定せずに呼び出しているため、SyntaxがデフォルトのRubyになってBoost.RegexのデフォルトのPerlと一致して使用できないバグ
==>Onigmoの関数仕様を確認しください。プログラム作成者が関数の仕様と、正規表現のSyntaxの種類を全く理解しておらず、Boost.RegexのSyntaxと一致するように実装しなかったことが原因です。６．検証
６．１ 検索を開いて、下記の通り設定する
３．の設定手順のうち、下記の項目のみ変更して、設定する。
［検索する文字列］
(?<a>[A-Z])(\g<a>)６．２ [次を検索]を実行する
６．３ 確認
正しくAAの文字が選択され、DC、BAも含むすべてのAからZの２文字の組が背景色緑色で強調表示される。６．１で［正規表現エンジン(G)］を既定(Boost.Regex)に変更すると、DC、BAは文字列選択と強調表示はされない。
\gは指定グループ名の「一致した結果」を呼び出しているため（SyntaxがPerlの場合）。６．１で［正規表現エンジン(G)］を既定(Boost.Regex)に、［検索する文字列］を
(?<a>[A-Z])(?&a)に変更すると、DC、BAも文字列選択と強調表示となる。
これが、３．で期待している結果になります。
(?& )は、指定グループ名の「正規表現」を呼び出しているため（SyntaxがPerlの場合）。すみません。上記の正規表現の部分にcodeタグを使用しなかったため、ダブルクォーテーションの文字が意図していない文字に変換されてしまいました。そのため、codeタグを入れたものを再度掲載します。
———————————
江村様いつもお世話になっております。
yasujiです。正規表現置換で、検索文字列を
["()]+(?:\r\n|[\r\n])|["()]+に設定し、置換文字列を空にして、特定行のみを行削除する置換を実行すると１行目のみ行削除され、以降は空行が残る不具合の連絡です。上記不具合の発生の再現手順は下記の通りです。
〔対象〕
v24.3.2 (64bit)〔使用環境〕
OS: Windows 10 Pro 64bit, ver 22H2〔再現手順〕
１．EmEditor 64bit ポータブル版を初期状態で起動
zipファイルから展開して、起動する。
初回のエディション選択は、Professionalを選択する。２．開いている文書タブに適当なテキストの入力
例えば、下記のようなテキストを文書タブに入力して未保存状態にする。"( AAAAAAAAAAAAAAA BBBBBBBBBBBBBB )" CCCCCCCCCCCC DDDDDDDDDDD ( AAAAAAAAAAAAAAA BBBBBBBBBBBBBB ) "( AAAAAAAAAAAAAAA BBBBBBBBBBBBBB )" -------３．置換を開いて、下記の通り設定する
［検索する文字列］
["()]+(?:\r\n|[\r\n])|["()]+［置換後の文字列］（空に設定する）
〔チェックボックス〕
チェックボックスすべて：OFF
〔ラジオボタン〕
［正規表現(X)］：ON［高度］
〔チェックボックス〕
［CRとLFを区別する(T)］：ON
［次を検索/前を検索で重ならない文字列のみ一致する(F)］：ON
上記以外のチェックボックスすべて：OFF
［正規表現エンジン(G)］：既定(Boost.Regex)
［正規表現で検索する追加行数(L)］：0４．すべて置換を実行する
５．結果の確認
１行目の “( は行ごと削除されるが、それ以降は空行になる。
本来は、条件に一致する行がすべて削除されなければならい。
［正規表現エンジン(G)］をOnigmoに変更しても同じ結果になる。AAAAAAAAAAAAAAA BBBBBBBBBBBBBB CCCCCCCCCCCC DDDDDDDDDDD AAAAAAAAAAAAAAA BBBBBBBBBBBBBB AAAAAAAAAAAAAAA BBBBBBBBBBBBBB -------６．検証
６．１ 置換を開いて、下記の通り設定する
３．の設定手順のうち、下記の項目のみ変更して、設定する。
［検索する文字列］
["()]+(?:\r\n|[\r\n])６．２ [すべて置換]を実行する
６．３ 確認
期待通りの下記の結果になる。本来は、５．の置換結果が下記と同一の結果にならなければならない。
最左から一致するものを優先的にマッチさせるため。AAAAAAAAAAAAAAA BBBBBBBBBBBBBB CCCCCCCCCCCC DDDDDDDDDDD AAAAAAAAAAAAAAA BBBBBBBBBBBBBB AAAAAAAAAAAAAAA BBBBBBBBBBBBBB -------７．検証２
７．１ Notepad++を開いて２．を入力する７．２ 置換を開いて、下記の通り設定する
３．の設定手順のうち、下記の項目のみ変更して、設定する。
［検索する文字列］
["()]+(?:\r\n|[\r\n])|["()]+［置換後の文字列］（空に設定する）
〔チェックボックス〕
［先頭/末尾から再検索(P)］：ON
上記以外のチェックボックスすべて：OFF
〔検索モード〕
［正規表現(G)］：ON
［.は改行と一致］：OFF７．２ [すべて置換]を実行する
７．３ 結果の確認
期待通りの下記の結果になる。AAAAAAAAAAAAAAA BBBBBBBBBBBBBB CCCCCCCCCCCC DDDDDDDDDDD AAAAAAAAAAAAAAA BBBBBBBBBBBBBB AAAAAAAAAAAAAAA BBBBBBBBBBBBBB -------江村様
yasujiです。
１日ほど待ちましたが、正規表現の要望を搭載した検討結果の回答が得られませんでした。
本来は、正規表現の要望を搭載したバージョンがリリースされたときに、品質が確保できているかをチェックするために、意図的に報告していなかった正規表現の不具合について、先ほど報告いたしました。これらの正規表現の不具合は、その議論からだいぶ後に見つけました。さすがに大丈夫だろうと思っていた矢先にまさかの不具合で焦りました。要望はまだかなうかもしれないと淡い期待を持っております。要望の検討結果の回答と、それを実装したバージョンのリリースを早めにお願いできればと思います。
議論から６カ月が立っているので、江村様の中では結論が出ているはずだと思っています。よろしくお願いします。
江村様
いつもお世話になっております。
yasujiです。RFC 5952 で、IPv6 アドレスを小文字のみで書くことが推奨されています。
そのようなRFCがあることを認知しておりませんでした。それであれば、初回のご回答にRFC 5952に準拠していると説明いただければ、大文字を含むIPv6アドレスは、認識しない技術仕様として理解できます。しかし、ログ解析では、小文字のIPv6アドレスのみを出力するような行儀のよいサーバソフトウェアはあまりなく、大文字も含むIPv6アドレスが多いので困ることには変わりはないです。
しかしながら、v24.0.903 では、大文字の表記も IPv6 アドレスとして認識するように変更しました。
https://jp.emeditor.com/forums/topic/emeditor-v24-1-preview-24-0-901/認識するIPv6アドレスとして、大文字表記IPv6アドレスも追加していただきありがとうございます。
v24.0.903で、大文字と小文字を含むIPv6アドレスが昇順／降順ともに正しく並べ替えられることを確認しました。
大文字を含むIPv6アドレスには対応されるつもりはないものと思っていましたが、追加対応のおかげでこれでようやっと使える機能になり非常に助かります。よろしくお願いします。
ご回答ありがとうございます。
上記の内容で試したところ、確かに昇順、降順で正しく並べ替えができました。
EmEditor の設定のプロパティのリンク ページで、IPv6 を有効にしておけば、IPv6 が強調表示されるため、わかりやすくなります。
上記機能は認知していませんでした。IPv6アドレスの強調表示を有効にしておけば、確かにどの表記形式を認識しているかがわかりやすくなりました。
RFC では、大文字や 0000 は許されていますが、小文字で :: を使用して表記しているのが一般的であり、その一般的な表記のみを IPv6 として認識しています。そのようにしないと、IPv6 ではない英数字の組み合わせが IPv6 として誤って認識されてしまい、多くのユーザーが期待した結果と異なる可能性があります。
説明いただいて揚げ足をとるようなことをして申し訳ないのですが、ネットワーク関係の技術を長くやっていた関係で、上記の「小文字で :: を使用して表記しているのが一般的であり」について言っていることはわかりますが、「一般的であり」という説明は「大多数がそのように使っている」という意味で解釈するため何を指して言っているのかの趣旨がわかりません。
ネットワーク機器などを数多く扱ってきましたが、その表記形式が一般的という状況については、一度も見たことも聞いたこともありません。IPv6については、RFCという標準規格がある以上それに準拠するのが一般的です。その「一般的であり」が、CISCOの技術仕様に合わせるというのであれば、おおむね納得できます。
ネットワークに関しては、大きな影響力を持っていて、規格上あいまいな部分はCISCOの機器の仕様に合わせるところがあるため。
ご参考までに、CISCOのIPv6 Addressing and Basic Connectivity Configuration Guideの説明の Example: IPv6 Addressing and IPv6 Routing Configuration を参照すると、IPv6アドレスは、0000は0として大文字小文字の混合表記で設定するサンプルが提示されています。
ネットワーク業界の大御所がこのような状況なので、「一般的であり」がどこのことを言っているのかわかりませんという意味です。私なりの解釈をすると、文章上の表現や細かい説明の仕方は人によると思いますが、下記のような趣旨での説明なら理解して納得できます。
=======
Windowsにおいては、IPv6アドレスはすべて小文字で、:で区切られた16進数は0のみか、0以外で始まる最大4桁で、0のみが連続する箇所は::で省略表記する仕様になっています。EmEditorは、Windowsで動作するので、WindowsのIPv6表記に一致させてWindowsユーザが混乱なく使用できるようにしています。したがって、RFCで定義されている大文字や0000などの表記形式には対応しておりません。
=======Windows 10において、コマンドプロンプトで確認すると、大小文字混合したIPv6の完全表記のIPv6アドレスをpingコマンドに渡して実行すると、結果表示で江村様の説明された表記仕様のとおりに「fe80::123:4567:89ab:cdef」と表記されます。
> ping -n 1 -w 100 fe80:0000:0000:0000:0123:4567:89AB:CDEF fe80::123:4567:89ab:cdef に ping を送信しています 32 バイトのデータ: 要求がタイムアウトしました。 fe80::123:4567:89ab:cdef の ping 統計: パケット数: 送信 = 1、受信 = 0、損失 = 1 (100% の損失)、ご回答いただいた江村様の説明で、[IPv6アドレス昇順に並べ替え]/[IPv6アドレス降順に並べ替え]の機能で並べ替えを行うために、前提とするIPv6表記形式は理解できました。
しかし、その前提となる技術仕様の情報が、下記のヘルプの項目に記載がありません。EmEditorのトップページでは、「目的別の使い方」にサーバ管理者が記載されていますので、私のような誤った理解でこれらの機能が使えないということが生じるのは想定できることだと思います。
EmEditor ヘルプ – [IPv6アドレス昇順に並べ替え] コマンド
EmEditor ヘルプ – [IPv6アドレス降順に並べ替え] コマンドしたがって、上記のヘルプ項目のなかに、江村様が説明した技術仕様を記載することが必須なのではないでしょうか？
少なくとも、ネットワーク技術を理解しているユーザからは、「使えない機能」という評価になってしまいます。
江村様はブログのほうでテクニカルレビューを書かれていますので、技術仕様を記載することは難なくできる思います。
もし、私が知らないだけで、別のところに情報があるのであれば、そのURLを教えていただければと思います。江村様
いつもお世話になっております。
yasujiです。上記の要望について、その後はいかがでしょうか？
要望を出してから、７日ほど経過しているので、少なくとも対応の可否は回答はできると思います。
また、対応いただける場合は、江村様のリソースの問題もあると思いますので、いつごろまでに対応できるのかについても教えていただきたいです。過去の投稿を確認したところ、2021年5月18日 9:31 pmにて「フォーラムのトピックタイトルの長さ制限について」のトピックタイトルで改善要望が出ていました。
しかし、要望を出したユーザの改善してほしいという考えに反して却下になっておりました。引用元：omusubi – #29819 – フォーラムのトピックタイトルの長さ制限について
フォーラムのトピックタイトルの最大の長さは80と表示されていますが、それより短くてもエラーになってしまい投稿できませんでした。
短くすることで投稿はできましたが情報が欠けてしまって内容が伝わるか不安になりましたので、表示どおりの長さにはできないでしょうか？
難しい場合は実際に登録できる長さや条件（全角で何文字など）を表示していただけないでしょうか？引用元：Yutaka Emura – #29828 – フォーラムのトピックタイトルの長さ制限について
omusubi 様
いつもお世話になっております。
これは WordPress の問題なので、私だけでは変更が難しいです。おそらく、パーセント エンコーディングに変換した時の長さの制限になると思います。
申し訳ありませんが、なるべく短い文にしてお使いください。よろしくお願い申し上げます。
上記が当時の江村様の回答内容なのですが、EmEditorを一人で開発してきた開発者としての回答ではなく、技術について詳しくない問い合わせセンターの出来の悪い担当者の回答です。
EmEditorには[Unicodeをパーセント エンコーディングに変換]機能がありますが、通常は実装するためにはエンコーディング規則などの仕様を調べて、その過程でどういう場面で使われるのか理解できるはずです。
[Unicodeをパーセント エンコーディングに変換]機能を外部の開発会社に依頼して実装してもらいそのままリリースしたということ以外では、上記の回答は成立しません。少なくとも、江村様が自力で苦労して実装されたのであれば、どのように使われているかはわかると思います。
Webのテキスト入力欄の文字列の文字数は、ブラウザ上で入力された文字列をもとに算出します。その文字列をパーセントエンコーディングしてから文字数を算出するのはWebアプリとしてあり得ません。ご参考：
MDN – Percent-encoding (パーセントエンコーディング)したがって、パーセントエンコーディングの知識もなく、使用しているWebの動作検証することもせず、経験の幅が狭く間違いがないと思い込んだ状態で回答をしているということが理解できます。
よろしくお願いいたします。
江村様
いつもお世話になっております。
yasujiです。ご回答ありがとうございます。
過去にログファイルサイズが200MBから800MBになるサーバのログのコピーをEmEditorを使用して解析調査をしていました。その作業では、特定のログを見つけ出して、目印としてその前後に容易に検索識別できるタグ文字列と空行を挿入する操作をして、その途中経過を保存しながら進めていました。
解析調査方法は、合意をとって進めていたのですが、本不具合で不特定位置の文字列が抜けたり、書き換わったりすると、意図せずにログ改ざんになってしまうことを恐れておりました。
当時、使用していたバージョンで、その不具合があったとなると、まずいことになる恐れがあったため、不具合の影響のあるバージョンをすべて提示を求めた次第です。解析調査は確か１年少し前に急ぎだと言われて作業した記憶があり、その時の正式リリースのものを使用していたと思うので、当時のバージョンは、v22.1.0からv22.1.4の範囲のどこかだった思います。
当時のログは、その作業完了後に削除したため、現在の手元にありません。
代わりに、作業していた関係でたまたま352MBのログファイルがあったため、v23.1.2を使いご提示された再現手順を試したところ変更がファイル保存されない不具合が発生したことを確認しました。不安だったため、当時使用していたバージョンのうち一つのv22.1.4について、上記と同じログファイルと再現手順を試しましたが、不具合は発生しなかったことを確認しました。
正式リリースの不具合修正を見たときは、見間違いかと思ったほど心中は穏やかではありませんでしたが、当時のバージョンで不具合が発生しないことを確認できたことで安堵できました。
当時、軽微なミス（取り返しが可能な）を２つ，３つ見つけると、大問題のように言ってくる少し変わった方が一緒にいまして、その方の目についてしまうとまずと思った次第です。
その方含めて、結果説明して合意はとってはいたのですが、その方が何を契機にそのように言ってくるのかがわからないところがあったため。過去のバージョンに遡って影響する不具合ではなかったことが確認できました。ありがとうございました。
