フォーラムの返信を作成しました。
- 投稿
いつもお世話になっております。
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について、上記と同じログファイルと再現手順を試しましたが、不具合は発生しなかったことを確認しました。
正式リリースの不具合修正を見たときは、見間違いかと思ったほど心中は穏やかではありませんでしたが、当時のバージョンで不具合が発生しないことを確認できたことで安堵できました。
当時、軽微なミス（取り返しが可能な）を２つ，３つ見つけると、大問題のように言ってくる少し変わった方が一緒にいまして、その方の目についてしまうとまずと思った次第です。
その方含めて、結果説明して合意はとってはいたのですが、その方が何を契機にそのように言ってくるのかがわからないところがあったため。過去のバージョンに遡って影響する不具合ではなかったことが確認できました。ありがとうございました。
「バグの出方」とは何のことをおっしゃっているのか、わからないのですが、検索だけでなくすべての機能においてバグは起こってはいけません。
「バグの出方」が何を言っているのか理解できないということは、ソフトウェア開発者に要求されるテストスキルが低くて実践的な実力はほとんどありません。と自白されているのと何ら変わりませんよ。
つまり、バグ（＝不具合）がどの機能にどういうバグ内容で出現しているか、それらを全体として俯瞰したときに、バグそのものが減少傾向にあるのか？または、依然としてバグが出続けているのか？を分析することを指しています。分析とは、バグそのものの重症度、機能別の出現箇所、出現深度（※１）などがどうなっているかを網羅的に把握することです。その分析結果に基づいて、ソフトウェアの品質が高いのか、低いのかを判断して、低いところは改善するための打ち手をいくつか考えて実施する。さらに、高いところは本当に高いのかをさらに疑って、さらにテストパターンを増やして厳しいテストを実施して、本当に品質が高いことを確認する。※１ 出現深度とは、バグの潜んでいる深さを指します。具体的なものはユーザ視点と開発者視点で定義はそれぞれありますが、一般的には、ユーザ視点だとすると、浅い箇所は通常操作でバグが出現する場合、深い箇所は複数の設定などの条件を満たさないと出現しない場合を意味します。私の経験してきたテストでは、言い方は人それぞれありますが、こういことも散々して来ました。
例えば、ソフト開発プロジェクトですと、バグ曲線というグラフを作って、テストケース数の消化率に応じて、バグがどのくらい出ているのかを分析します。そのグラフと検出したバグの内容を考慮して、バグ検出が収束傾向（減少傾向の意）あるかどうか判断して、さらなる打ち手を検討することになります。
EmEditor v23.1 previewのリリース情報を見ると、すべての「クラッシュ」バグをカウントすると１２件あり、その中には上記でいう浅い箇所でユーザに直接大きな影響を与えるクラッシュバグの記載も含まれています。そして、これらのクラッシュバグは、どのバージョンで入り込んだのか情報がないため、このv23.1 previewより前のバージョンから存在していたと判断するのが普通です。
それらを踏まえて、現在のテスト内容は、バグをたたき出すためのテストケースを作成できているか、「～をしているはずだからこれはテストする必要がない」と考えて当たり前にできることもテストケースに設定していないのではないか、ということを非常に心配していますよという意味で書きました。
特に、正規表現を使用した検索機能についていえば、私が報告してきたクラッシュバグについて、本来は江村様がテストで事前に発見して、他に類似はないかも含めて根本修正までするのが普通だと思いますが、それができていませんでした。したがって、バグをたたき出すための思い込みを一切排除した厳しいテストケース、テストデータによるテストケースを作成する考えがあるように見えません。
ご理解しているか怪しいのであえて言いますが、はっきり言って端的に言えば、ソフトウェア開発する人間にバグがあります。例えば、コーディング中に何か別のことをするために手を動かして、自覚なしにキーボードのキーに触れて、知らない間に文字が入力されて、運悪く文字列定義の中だったとします。もし、自分はそんなミスはありえない／しないと考えているとまず気が付くことはないでしょう。そのたった数文字が命取りで、後々バグの原因探しで１週間奔走するということにもつながります。
したがって、私も私自身の作業を信じていません。例えば、ソースファイル内で複数個所で使われている変数名を置換で変更する際は、必ず変更前ファイルと変更後ファイルのdiffをとって、すべての変更箇所が、自分が意図した通りかどうかを確認しています。ただし、前述したことを実現する機能を持っていて使う場合でも、初期はdiffでチェックして性能確認といろいろなケースの実績を蓄積し、もう大丈夫だろう判断になれば、その機能を信用してdiffチェック作業を省略して作業の軽減をします。理由：バグの出方から気になって気になって仕方がないのと、この機能についてバグなしで安定して動作しないと致命的なため。
私が書いた上記の一文は、本来は開発者としてどういう意味を含んでいるのかを理解していただきたかった内容です。付け加えるなら、以前たくさん書くと理解できないと言われたので、あれこれ言わずにシンプルに書きました。
EmEditorの安定性は非常に重要であり、機能の追加よりも安定性の向上が遥かに重要だと考えています。私たちはAzure DevOps上の「Git」リポジトリから3つのパイプラインを用意し、自動テストを実行しています。毎日数回ソースコードを変更し、コミットすると自動的にテストが実行されるようになっています。巨大なファイルを使用した大規模なテストは毎晩数時間かけて自動実行しています。
テストは何のためにするのかは正しくご理解されていないように見えます。
テスト自体がコミットごとに自動実行するか、手動実行するかは、テスト忘れ防止やテスト工数を削減するための手段であって、これだけではバグ検出して品質を向上することはできません。
バグが見つかるたびに既存のテストケースではなぜ見つけられなかったのか？、そもそもなぜそのバグが入り込んだのか？を考えて、少なくともそれらをカバーする網羅的なテストケースを追加しなければなりません。また、最近のバージョンではクラッシュレポートを受け付ける機能も追加しました。これは非常に効果的であり、ユーザー様からクラッシュレポートが送信されると私の元にすぐに通知が届き、その日のうちに問題を見つけ修正することができます。もちろん、バグは避けるべきですが、テスト漏れやバグがリリースに残ることもあるかもしれません。完璧なソフトウェアは存在しません。
「クラッシュレポートを受け付ける機能」については、どのバージョンから搭載されたかわかりませんが、少なくとも去年の正規表現関連不具合でクラッシュしたことが、原因特定で試したのを含めいて２０回以上ありましたが、一度もクラッシュレポート機能が動作するところを見たことはありません。すべていきなり強制終了でした。
文章上の表現だけだと思うのですが、念のため言っておきますと、「バグは避けるべき」ではなく、「バグはなくすべき」と考えなければなりません。つまり、常にバグが発生しないためにはどのようにコードを書くべきか？（if文に記載する条件一つについても）、クラス構成やデータ構造はこのままでよいか？を徹底的に考えて、考えたコード単位の動作検証して、実装に反映させていく必要があります。
「バグは避けるべき」と甘く考えるソフトウェア開発者には、バグの少ない高品質なソフトウェアは作れません。しかし、バグが見つかっても迅速に対応することでユーザー様の信頼を得ていると思います。もしかすると、頻繁な更新と多くのバグ修正があるため、そのように感じられているかもしれませんが、バグを放置するよりも更新を提供する方がユーザー様のためになるのではないでしょうか。
ユーザの信頼を得ることについて、考え違いをしているので、ここでもあえて言わせていただきます。
見つかったバグで、ユーザはどのような被害を被ったかまたは被るかを考えたことはありますか？
上の方で書きましたが、例えば、クラッシュを引き起こすバグは、ユーザが作業中の未保存のテキストデータをすべて損失させます。回復手段はありません。あるとすれば、定期的にスナップショットを保存するくらいでしょう。
さらには、そのユーザがそのテキストデータを作成した時間（工数）も失い、もういちど同じアウトプットを作成するために最低でも同一の時間（工数）を必要とします。そのバグが原因でユーザ本人に仕事を依頼した依頼主に渡すはずのアウトプットが、予期せずに損失して真っ青な顔で期限ぎりぎりまでに再作成せざるをえない状況に追い込んでいたらどうでしょうか？
ユーザ本人が、EmEditorが原因だとわかっていても、依頼主にそんなことは言えませんよ。言ったらどうなると思いますか？簡単です、評価が下がります。つまり、依頼主からすれば、この人は自分の仕事の遅れをバグることなんてないテキストエディタを言い訳にする人なのかと認識されて、その組織で重要度の高い仕事の場合は、外されてしまうリスクがあります。１度ならまだしも、何度もあれば重要な仕事は任せてもらえなくなります。
したがって、そのような経験をしたユーザであれば、安定してテキスト編集ができるEmEditorの信用がすべてなくなり、怖くて使えないのでほかのテキストエディタに切り替えて仕事を続けることをするのが普通の判断と対応になります。
そのユーザにバグは修正しましたこれで安心して使ってくださいという意味で、手早く更新を提供しても、ユーザが使ってみたら類似の使い方でクラッシュして再度テキストデータを損失する経験をしたらどう考えると思いますか？
難しくはないですよ。このソフトウェアと開発元は信用してはいけないになります。例えば、ソフトウェアではないですが、ソフトウェアのクラッシュバグ相当の事例として、ボーイング社の旅客機のドアが航行中吹き飛んだ事件がありました。
BBC News Japan – 【解説】 米ボーイングにとって深刻な問題 主力機のドアが航行中に飛んだ事故離陸後の上昇中に発生した事故で、全員が運よくシートベルトをしていたので、誰一人外へ投げ出されずに済みました。
もし、江村様がこの旅客機の吹き飛んだドアの座席にシートベルトをして着席して、この事故を経験して無事に生還できたとします。
そのあとに、仕事でどうしても旅客機で移動する必要があるとしたときに、もう一度同型の旅客機乗りたいと思いますか？あるいは、同一メーカのすべての旅客機に乗りたいと思いますか？
私なら、金額が少々高くついても、命には代えられないので、可能な限りボーイング社の旅客機は避けて、かついずれのドアからも距離をとった座先を予約します。
この例えの続きでいえば、ボーイング社が迅速に問題を修正しましたので、安心して同型機にご搭乗くださいと修正版同型機をリリースしたとして、客は信用しますでしょうか？しかも、調べてみるとほかにもボーイング社の旅客機で不具合が起きていることがわかった。
このような状況では、事故経験の有無に関係なく客はドアどころか通常の窓も吹き飛ぶのではないかと疑心暗鬼になります。この事故に遭遇したらなくなるのは自分の命になるため。
飛行機事故の事例を出したのは、ソフトウェアのバグも状況によってどれくらいの影響をユーザに与えるのかを理解いただくためです。ユーザが何をもって信用するかは、「対応の迅速さ」ではありません、「バグを完全解消した実績」です。対応の迅速さを売りにする人は山ほどいますが、仕事はいい加減な人ばかりです。
したがって、実績以外に信用に足るものはありません。もちろん、短い時間でいい仕事（言ってもいないことで、頼んだ側の事情を汲み取って次の仕事に手間なく取り掛かれるようにアウトプットをフォーマット込みで考えて出してくれる）する人もいますが、全体としては少ないです。[高度] ダイアログの [正規表現「.」が改行コードに一致することができる] オプションがこれ相当します。
regexオプションのsに相当しますと説明したいのだと思いますが、それだけでは機能しません。それ以外に、[高度]ダイアログの[正規表現で検索する追加行数]を検索対象の文書の合計行数以上に設定しなければなりません。
二つの設定項目を適切に設定して、初めてregexオプションのsを設定したのと同様に正規表現検索できるようになります。正規表現そのものの理解と、実装されている上記のオプションの関係が理解できているかが心配になったので書きます。
２．と３．は、２つでワンセットです。最初は、２．だけでしたが、これだけだとこちらの意図が伝わわず変な実装をされる不安があったため、３．を書き足しました。
この不安は、残念ながら的中してしまいました。3.～10. については検討します。
したがって、２．～１０．までを検討範囲としてください。
当然なのですが、この中には文章として表現されていない「隠された要求仕様」が含まれています。くれぐれも慎重に深く洞察いただいて、考えていただきますようお願いします。というものの、まさかの実装を検討するということでしたので、少し書きます（追加の要求仕様の実装自体は却下されたと認識したので、実現はあきらめていました。それならそれでなぜの理由を聞いて、このやり取りは終わりにするつもりでいました）。
UIに実装する際の文言表現（ユーザがこの文言表現でどういう機能か？どういう効果があるか？を正しく理解できるか？）、UI上の機能配置の仕方（オプションは、[高度]ダイアログに配置したほうがいいか、[検索]ウィンドウに配置したほうがいいか）についても「隠された要求仕様」に含まれています。さらには、強く関係する他の機能もどうするかも含んでいます。
EmEditorのメニューで選べる機能名は、何のために使うのか、どういう効果があるのかが、わからない名称のものが散見されます。もし過去にその機能を要求した人がいたとしたらその本人にはわかるでしょうが、私にはよくわかりません。したがって、こういう作業にはよい機能があっても、実質その機能が使えない状態になっているため。はっきりと言えば、検索・置換機能についていえば、動作挙動、主要な名称については、世の中で多く使われて通用しているものに合わせていただきたい（最低でも、それらを踏まえたものにしてほしい）。ここから外れるのであれば、ヘルプでこれを設定するとBoost.regexのどのオプションを設定したことになるのかなどを説明を記載してほしい。特に、江村様が実装された検索挙動については、明確にわかるようにヘルプに記載するべきです。
長く書いてしまいましたが、いずれにしても実装却下されたと認識していた追加仕様について、実装を検討されるとの回答でしたので、期待はせずに運が良ければ希望がかなうかもしれない程度に考えておきます。
お世話になっておいります。
yasujiです。#31515からの引用：
– [高度] ダイアログ ボックスに [次を検索/前を検索で重ならない文字列のみ一致する] チェック ボックスを追加しました。
https://jp.emeditor.com/forums/topic/emeditor-v23-2-preview-23-1-901/
上記の機能をv23.1.901にて、検索ウィンドウで[高度]->[次を検索/前を検索で重ならない文字列のみ一致する]をチェックありに設定して、[次を検索]の動作が要望通り動作することを確認しました。
#31421から引用：
その検索機能を搭載いただけるなら、検索と置換をセットで下記の仕様をベースにご検討をお願いしたいです。
Boost regex/Onigumo仕様のURLを記載した。Boost regex仕様は、最新版を参照しましたが、EmEditorバージョンに記載されているものよりも新しいので、現状のままかバージョンアップされるかはお任せします。上記要求仕様の１．～１０．について、要望を実装されなかった理由の説明をお願いできますでしょうか？
私の要望も江村様からの理由説明の求めに応じてすべて書きましたので、江村様も実装しなかった理由を説明してほしいです。よろしくお願いします。
すません。書いたつもりで、記載漏れがありました。
EmEditor で、設定のプロパティやカスタマイズで、すべてのページを選択すると、それだけ多くの GUI ハンドルを消費します。その違いはありますが、それが原因で、ご指摘のような問題が発生することは、通常は考えにくいです。おそらく、何か他の設定が関係しているのだと思います。[カスタマイズ] ダイアログの [ウィンドウ] ページで、ダイアログ ボックスのフォントは変更されていないでしょうか? もし変更されていたら、[リセット] をクリックして既定に戻してください。
EmEditorは、手順にある通りEmEditorポータブル版を使用して、zipファイルを解凍後に起動して、何ら設定変更せずに動作させております。
マウスツール（ロジクール）をお使いだそうですが、それをアンインストールしてお試しください。ウィルス対策ソフトも、一時的に無効にして、問題が改善しないかお試しください。
マウスに付属の常駐型マウス制御ツールはアンインストール、ウイルス対策ソフトも一時的に無効にしましたが、問題は改善されませんでした。
一つ上の私の返信の通り、あとは、私自身で対応します。
よろしくお願いします。
いつもお世話になっております。
yasujiです。動画をお送りいただき、ありがとうございます。問題の現象は、こちらでは再現できませんでした。グラフィック カードやマウスは何をお使いでしょうか?
現象が再現しなかったこと了解しました。
グラフィックカードは、拡張カードは使用せず、CPU内蔵GPUを使用しています。
内蔵GPU：Intel(R) UHD Graphics 630
マウス： Logicool G502 LIGHTSPEEDワイヤレスさらに、デバイス マネージャーで、マウスのドライバ、およびグラフィック ドライバを最新に更新できないかお試しください。マウス ドライバを更新するには、次の手順に従ってください。
1. デバイスマネージャを開きます。[スタート]ボタンを右クリックし、[デバイスマネージャ]をクリックします。
2. デバイスマネージャウィンドウで、[マウスとその他のポインティングデバイス]を展開します。
3. リスト内のマウスデバイスを見つけて、右クリックし、[ドライバーソフトウェアの更新]をクリックします。
4. [ドライバーソフトウェアの更新]ウィンドウが表示されます。ここで、以下のいずれかの方法を選択します。
– [自動的に検索してインストールする]をクリックして、Windowsが最新のドライバをインターネットからダウンロードしインストールする。
– [コンピューター上のドライバーソフトウェアを参照してインストールする]をクリックし、ローカルに保存している最新のドライバを選択する。
5. 上記の手順でドライバの更新が完了しました。内蔵GPUのドライバは、ご案内の手順にて最新であることを確認し、念のため、インテル® ドライバー & サポート・アシスタントでも調べましたが同様でした。
マウスのドライバもご案内の手順にて最新であることを確認しました。また、Windows の設定のマウス、またはコントロール パネルの [マウスのプロパティ] で、何か設定を変えていないでしょうか? 画面図は、以下のリンクを参考にしてください。
https://www.sony.com/articleimage/servlet/servlet.FileDownload?file=0155F000007WZ4mQAG
特に、[ポインターの軌跡を表示する] がチェックされていないですか? もしチェックされていたらこれを無効にしてお試しください。
[マウスのプロパティ]については、基本的に設定を変更していません。[ポインターの軌跡を表示する]は、無効（チェック無し）にしております。
以上を確認していただいた上で、まだ問題が発生する場合、もしよろしければ、大変お手数ですが、次のような手順を行っていただけると幸いです。
なお、EmEditorは、手順にある通りEmEditorポータブル版を使用して、zipファイルを解凍後に起動して、何ら設定変更せずに動作させた結果を確認して報告しております。
報告した手順で実施いただければ、同一設定での動作確認ができます。いろいろと確認すべき点の情報をいただきありがとうございました。
これらのことから、私のPC環境特有の問題ということがわかりました。
おかげさまで原因切り分けがしやすくなりました。あとは、私自身で対応します。
よろしくお願いします。
江村様
いつもお世話になっております。
yasujiです。CPU、メモリの情報は、下記のとおりです。
CPU: Intel Core i9-10850K 3.60GHz
Memory: 32 GBytes (DDR4)動画のほうは、お問い合わせフォームの方からアップロードURLを確認して、そこへアップロードいたします。
よろしくお願いします。
江村様
いつもお世話になっております。
yasujiです。言葉の行き違いだったといことで、了解いたしました。
ご検討いただけるということですので、この件に関してご連絡いただけるまで、しばらくお待ちいたします。よろしくお願いいたします。
江村様
yasujiです。
現在、問い合わせているこの事象についてどうなっているのでしょうか？
後ろでエンジニアに丸投げしているのは、すでに感じておりますが、江村様で十分に確認ができる内容です。
せめて再現確認の有無と、どう対応されるのかの方針は回答できるのではないでしょうか？
そうでないと、何の仕事もしていないことになりますよ。江村様
yasujiです。
新規の正規表現の不具合２件（22.9.910においても発生） – #31419の私の説明を踏まえて、かつ上記の要望を読んで、その結果が上記の回答ですか？ユーザをなめるのもいい加減していただけますか？
上記で書いた内容は、 新規の正規表現の不具合２件（22.9.910においても発生） – #31412で先に書ける内容ですよね？
つまり、腹が立ったから、この人の提案は切って捨てて、労力を無駄にさせてやろうということですよね？
腹が立つのは勝手ですが、あなた以上に私は正規表現の不具合による被害、並びに動作不良、検索動作の根本的な考え方が世の中と異なっている点で、非常に腸が煮えくり返る状態で、ここまでの対応をしてきていることをしっかり理解してください。
江村様の対応が悪いから、こうなるのですよ。念のため、誤解がないように書いておきますと、[検索] ダイアログの [一致する文字列を数える] を設定しておけば、yasuji 様の希望通り、検索対象のテキスト文書の中で検索文字列が重複なくどこに何個出現するかを、ステータス バーに表示します。
上記の要望の内容を読んだ結果、私は「検索文字列が重複なくどこに何個出現するか」を望んでいると理解したのですか？
申し訳ないのですが、文章の読解力はありますか？どこをどう言う風に理解したらそうなるのか説明してください。下記の通りに動作する検索機能と置換機能の搭載を希望いたします。
希望する検索の挙動は、下記のような条件を用意した場合、[次を検索] (F3) を押下すると、１回目は先頭から１文字目からのAAを選択、２回目は先頭から３文字目からのAAを選択、これ以上選択できるものがないため検索が終了する（一致する文字列はもうないというメッセージが表示される）というものです。
検索ウィンドウオプション：
「正規表現(X)」または「(無し)(O)」
テキスト文書上のカーソル位置：文書の最先頭
検索文字列：
AA
テキスト文書：
AAAAA上記の要望は、無視されるのですか？
江村様が、理由を書けと言ってきたので、理由を書きました。さらに、過去のやり取りから変な実装されると困るので、具体的な要求定義内容を書きました。
Boos regexを実装しているなら、確実にそのドキュメントを読んでいるはずなのですが。そこに書いてあることで、ソースコードでどのように実装したか理解していれば、少なくとも開発の事情を考慮して、私の内容をいくつかこういう形で実装することでしたらできますがいかがでしょうか？というくらいの提案があってしかるべきでしょう。私の要望を踏まえて、どのように実現できるかのご提案をお待ちしております。
ここまで書かせたのですから、必ず具体的なご提案をいただけますよね？まさか、しっかりした理由と内容に対して、３行の回答で終わりではないですよね？
