- 投稿
いつもお世話になっております。
yasujiです。下記の通りに動作する検索機能と置換機能の搭載を希望いたします。
希望する検索の挙動は、下記のような条件を用意した場合、[次を検索] (F3) を押下すると、１回目は先頭から１文字目からのAAを選択、２回目は先頭から３文字目からのAAを選択、これ以上選択できるものがないため検索が終了する（一致する文字列はもうないというメッセージが表示される）というものです。
検索ウィンドウオプション：
「正規表現(X)」または「(無し)(O)」
テキスト文書上のカーソル位置：文書の最先頭
検索文字列：
AA
テキスト文書：
AAAAA理由：
検索機能は、検索対象のテキスト文書の中で検索文字列が重複なくどこに何個出現しているかを特定する機能です。既存の検索機能は、検索機能の必須条件を満たしていません。
私が知っている範囲での正規表現検索機能を持つツールの例をいくつかあげます。
有名な正規表現検索に対応したコマンドは、Linux OS(Ubuntu, CentOS, Redhat)であれば、sed, grep, egrepになり、Windows 10であれば、findstrコマンドになると思います。
テキストエディタであれば、Linux OSではシェル上で動作するemacs, nano, vimあたりが有名でよく使われます。Windowsだと、EmEditor以外ですと、Sakura Editor, 秀丸エディタ, Notepad++などフリーを交えて有名どころで使われています。これらの正規表現検索コマンドとテキストエディタは、すべて上記で説明した検索動作になっており、EmEditorのみこれらとは異なる検索動作のため結果が一部異なっています。このため、他のツールで当たり前に検索できることが全くできず、実作業にて事実上使えない状況のため。他のツールを使い結果検証をすることがたびたびあり結果が一致せずに実務で大変困っているため。
正規表現の検索で下記の条件での検索において、正規表現検索文字列１を設定して[次を検索]を押下し続けると、本来は正規表現検索文字列２と同様に１行ずつ選択されるはずが、選択範囲が一文字ずつ減少する謎動作をして、長年正規表現文字列作成での苦心と苦悩（本来は不要のはずが、正規表現検索文字列２の表現をしないと正規表現の動作仕様と一致しなかった）から解放してほしいため。
テキスト文書：本日は晴天なり aaaaaaaaaaaaaaaaaa bbbbbbbbbbbbbbbbb正規表現検索文字列１：
.+
正規表現検索文字列２：
^.+$
正規表現を選択、その他のオプションはすべてクリア
当時、いろいろ調べてmオプションが使われていると推測していました。
本当はsオプションを使用したかったのですができなかったため、\nを追加して次の行のマッチ条件を入れてなどして複数行マッチに苦労しました。
なぜ、こんなことになるのか長年の謎で正規表現ライブラリの動作仕様かと思ってあきらめていました。まさかの内容で今回で謎が解けました。新検索置換機能の機能名称についての私案：
現在の検索置換機能の名称を「パターン検索」、「パターン置換」と改名いただき、そのうえで私が説明した検索のアルゴリズムで「検索」、「置換」の機能を新規で下記の仕様要望で実装いただきたい。
理由：この実装方式が、他の文字列検索コマンドやテキストエディタと検索と置換の動作が同一になり、現行ユーザに対して保有している検索ノウハウと一致させることで大幅に作業効率を向上させることができるため。
これ以外をお考えの場合は、私にアイディアはないため江村様の方でご検討いただければ幸いです。その検索機能を搭載いただけるなら、検索と置換をセットで下記の仕様をベースにご検討をお願いしたいです。
Boost regex/Onigumo仕様のURLを記載した。Boost regex仕様は、最新版を参照しましたが、EmEditorバージョンに記載されているものよりも新しいので、現状のままかバージョンアップされるかはお任せします。
１．〔仕様〕ここまで踏み込むのは失礼とは思いますが、ソースコードの実装はシンプルにかつ最良のコード実装になるようにお願いいたします。
理由：バグの出方から気になって気になって仕方がないのと、この機能についてバグなしで安定して動作しないと致命的なため。
２．〔仕様〕正規表現本来のregexオプションのs, mを明示的に使用できるようにしてほしい（デフォルトはm）。
理由：正規表現本来定義されているオプションを他のテキストコマンド同様に使用できるようすることで使用感を一致される。
sはシングルライン（改行コードを無視して一行として解釈する）、mはマルチライン（改行コードを解釈して複数行として解釈する）の意味。
Perl regex仕様：
Regexp Quote-Like Operators
https://perldoc.perl.org/perlop#Regexp-Quote-Like-Operators
–> Options (specified by the following modifiers) are: にs, mの機能と意味が記載されている。
boost regex仕様：
Options for Perl Regular Expressions
https://www.boost.org/doc/libs/1_84_0/libs/regex/doc/html/boost_regex/ref/syntax_option_type/syntax_option_type_perl.html
–> 私の理解ですと、デフォルトが m になっていて、no_mod_mを指定すると s の挙動になると思っています。
match_flag_type
https://www.boost.org/doc/libs/1_84_0/libs/regex/doc/html/boost_regex/ref/match_flag_type.html
Perlの正規表現をマスターしよう
https://perlzemi.com/blog/20100827127859.html
–> 「正規表現のオプション」の章にsとmの正しい説明が書かれています。s,mの機能名称はPerlの仕様を正として理解したほうが無難です。
３．〔仕様〕新検索置換機能では、現時点の検索ウィンドウ -> 高度(V)… -> 正規表現で検索する追加行数(L)は廃止いただきたい。
理由：このような機能は上記説明したどのテキスト検索コマンド、テキストエディタにはないため。
本来使用できるregexオプションのsを使用することで、不要な機能のため。
４．〔仕様〕Perl Regular Expressionsを使用していることがわかるようにUI上で明示と、
新検索置換機能のウィンドウ内に対応している正規表現の書式について、EmEditorヘルプリンク、詳細版（Boost regex正規表現書式仕様、Perl regex正規表現書式仕様）リンクを配置してほしい。
デフォルトは非表示なっていて、ボタンを押下するとウィンドウが広がって、リンク情報が表示されるとありがたい。
理由：機能の詳細情報は、その機能の近くに配置することで、何も悩むことなく対応している正規表現書式の詳細説明にアクセスでき、作業効率が飛躍的に向上するため。
５．〔仕様〕sed, grep, emacs(POSIX Basic Regular Expressions), egrep, awk(POSIX Extended Regular Expressions)のオプションを必要に応じて使用できるようにしてほしい
理由：上記で説明した通り、正規表現はlinuxでは多用されているため、boost regexで対応している各コマンドの正規表現書式に対応すると、そのコマンドの検索ノウハウがそのまま使えるため。
それらも併用しているユーザは喜ぶと思います。私の知る限りこのオプション機能があるWindows向けのテキストエディターははないです。
サーバで多く使われているlinuxユーザに訴求するのであればお勧めします。boost regexが標準サポートしており、おそらくオプションの切り替えに対応するだけで実装できるため。
boost regex仕様：
Options for POSIX Extended Regular Expressions
https://www.boost.org/doc/libs/1_84_0/libs/regex/doc/html/boost_regex/ref/syntax_option_type/syntax_option_type_extended.html
Options for POSIX Basic Regular Expressions
https://www.boost.org/doc/libs/1_84_0/libs/regex/doc/html/boost_regex/ref/syntax_option_type/syntax_option_type_basic.html
６．〔仕様〕正規表現の書式は、半角スラッシュ(/)の囲い文字を使用せずに直接正規表現文字列自体を検索文字列や、置換文字列に入力する形にしてほしい（現状の検索ウィンドウの状態を維持してほしい）
理由：WindowsのUIとして、現状の検索文字列、置換文字列の入力UIが使いやすい。
もし、半角スラッシュ(/)囲い文字を使用する正規表現書式を追加する場合は、前述のUI中に切り替えタブかボンタンを用意して切り替えられる方式での実装をお願いしたい。
慣れたUIがいきなり変わるとそれを習得するのに時間がかかり、今まで実現できていた作業効率に大きな影響を与えるため。
７．〔仕様〕検索文字列の複数行表示に右端で折り返す機能をつけてほしい。可能ならデフォルトとして設定できEmEditorの再起動もその設定が残るようにしてほしい
理由：正規表現の初級レベルですと、１行あればたいてい事足りますが、上級以上になると複雑な長い正規表現文字列になることが多く、現状でEnterキーによる改行を入れる必要があります。
しかし、改行を入れると正規表現の\nまたは\r\nと解釈されてしまい、意図した正規表現検索ができない、それを避けると結局１行になるため正規表現文字列を俯瞰して作成することができないため。
８．〔仕様〕Onigumoについては、上記の仕様に一致するように実装してほしい。
〔注意〕ONIG_OPTION_SINGLELINEが、mオプション相当、ONIG_OPTION_MULTILINEが、sオプション相当とboost regexのオプションと逆になっている。
オプション名を安易に信じずに中身の設定内容を確認して、boost regexの仕様と合わせていただきたい。亜種は、こういう罠があるので要注意です。
Onigmo インターフェース Version 6.1.2 2017/05/10
https://github.com/k-takata/Onigmo/blob/master/doc/API.ja
鬼雲 (鬼車改) 正規表現 Version 6.1.0 2016/12/25
https://github.com/k-takata/Onigmo/blob/master/doc/RE.ja理由：boost regex仕様と一致させることで、ユーザがスムーズに使用できるようするため。
９．〔仕様〕Onigumoについては、正規表現パターン文法定義のONIG_SYNTAX_PERL、ONIG_SYNTAX_EMACS、ONIG_SYNTAX_GREPを優先実装してほしい。
それらとONIG_SYNTAX_DEFAULT以外のものは、ご検討の上できれば実装してほしい。
理由：正規表現はlinuxでは多用されているため、各コマンドの正規表現書式に対応すると、そのコマンドの検索ノウハウがそのまま使えるため。
その他は、プログラム言語対応で前述と同様の理由のため。
ONIG_SYNTAX_DEFAULTに対応しないのはバージョンアップで設定値が暗黙で変更されてバグになるおそれがあるため。
１０．〔仕様〕[次を検索]と[前を検索]のボタンのいずれかを一回のみ押下した際の検索文字列に一致する箇所の背景色を緑色した結果と、
再度いずれかのボタンを押下した際の文字列選択がすべてピタリと一致するようにしてほしい。
理由：置換を実行する前に検索文字列が、意図した文字列にすべて一致していることを事前に確認してすべて置換をしたいため。前向きなご検討をよろしくお願いいたします。
いつもお世話になっております。江村です。
念のため、誤解がないように書いておきますと、[検索] ダイアログの [一致する文字列を数える] を設定しておけば、yasuji 様の希望通り、検索対象のテキスト文書の中で検索文字列が重複なくどこに何個出現するかを、ステータス バーに表示します。また、[置換] や [すべて置換] も yasuji 様の希望の動作になります。つまり、[次を検索] とそのほかの動作が異なるということになります。
よろしくお願いいたします。
江村様
yasujiです。
新規の正規表現の不具合２件（22.9.910においても発生） – #31419の私の説明を踏まえて、かつ上記の要望を読んで、その結果が上記の回答ですか？ユーザをなめるのもいい加減していただけますか？
上記で書いた内容は、 新規の正規表現の不具合２件（22.9.910においても発生） – #31412で先に書ける内容ですよね？
つまり、腹が立ったから、この人の提案は切って捨てて、労力を無駄にさせてやろうということですよね？
腹が立つのは勝手ですが、あなた以上に私は正規表現の不具合による被害、並びに動作不良、検索動作の根本的な考え方が世の中と異なっている点で、非常に腸が煮えくり返る状態で、ここまでの対応をしてきていることをしっかり理解してください。
江村様の対応が悪いから、こうなるのですよ。念のため、誤解がないように書いておきますと、[検索] ダイアログの [一致する文字列を数える] を設定しておけば、yasuji 様の希望通り、検索対象のテキスト文書の中で検索文字列が重複なくどこに何個出現するかを、ステータス バーに表示します。
上記の要望の内容を読んだ結果、私は「検索文字列が重複なくどこに何個出現するか」を望んでいると理解したのですか？
申し訳ないのですが、文章の読解力はありますか？どこをどう言う風に理解したらそうなるのか説明してください。下記の通りに動作する検索機能と置換機能の搭載を希望いたします。
希望する検索の挙動は、下記のような条件を用意した場合、[次を検索] (F3) を押下すると、１回目は先頭から１文字目からのAAを選択、２回目は先頭から３文字目からのAAを選択、これ以上選択できるものがないため検索が終了する（一致する文字列はもうないというメッセージが表示される）というものです。
検索ウィンドウオプション：
「正規表現(X)」または「(無し)(O)」
テキスト文書上のカーソル位置：文書の最先頭
検索文字列：
AA
テキスト文書：
AAAAA上記の要望は、無視されるのですか？
江村様が、理由を書けと言ってきたので、理由を書きました。さらに、過去のやり取りから変な実装されると困るので、具体的な要求定義内容を書きました。
Boos regexを実装しているなら、確実にそのドキュメントを読んでいるはずなのですが。そこに書いてあることで、ソースコードでどのように実装したか理解していれば、少なくとも開発の事情を考慮して、私の内容をいくつかこういう形で実装することでしたらできますがいかがでしょうか？というくらいの提案があってしかるべきでしょう。私の要望を踏まえて、どのように実現できるかのご提案をお待ちしております。
ここまで書かせたのですから、必ず具体的なご提案をいただけますよね？まさか、しっかりした理由と内容に対して、３行の回答で終わりではないですよね？いつもお世話になっております。江村です。
文章の読解力はありますか？
申し訳ありませんが、私は、現在、米国在住の米国人であり、日本語の読解力は低いと言わざるをえません。申し訳ありませんが、箇条書きにしてわかりやすく簡潔に書いていただけると幸いです。
ユーザをなめるのもいい加減していただけますか？
そのように受け取られてしまったのでしたら、大変申し訳ありません。お詫び申し上げます。
なお、yasuji 様のご希望のオプションの追加は検討しております。追加できましたら、ご連絡いたしますので、試していただき、その後、フィードバックがありましたら、またご連絡ください。
この度は、不快な思いをさせてしまい、大変申し訳ありませんでした。
よろしくお願いいたします。
江村様
いつもお世話になっております。
yasujiです。言葉の行き違いだったといことで、了解いたしました。
ご検討いただけるということですので、この件に関してご連絡いただけるまで、しばらくお待ちいたします。よろしくお願いいたします。
いつもお世話になっております。江村です。
さきほど公開した v23.1.901 で対応いたしました。
– [高度] ダイアログ ボックスに [次を検索/前を検索で重ならない文字列のみ一致する] チェック ボックスを追加しました。
https://jp.emeditor.com/forums/topic/emeditor-v23-2-preview-23-1-901/
よろしくお願いいたします。
お世話になっておいります。
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の安定性は非常に重要であり、機能の追加よりも安定性の向上が遥かに重要だと考えています。私たちはAzure DevOps上の「Git」リポジトリから3つのパイプラインを用意し、自動テストを実行しています。毎日数回ソースコードを変更し、コミットすると自動的にテストが実行されるようになっています。巨大なファイルを使用した大規模なテストは毎晩数時間かけて自動実行しています。また、最近のバージョンではクラッシュレポートを受け付ける機能も追加しました。これは非常に効果的であり、ユーザー様からクラッシュレポートが送信されると私の元にすぐに通知が届き、その日のうちに問題を見つけ修正することができます。もちろん、バグは避けるべきですが、テスト漏れやバグがリリースに残ることもあるかもしれません。完璧なソフトウェアは存在しません。しかし、バグが見つかっても迅速に対応することでユーザー様の信頼を得ていると思います。もしかすると、頻繁な更新と多くのバグ修正があるため、そのように感じられているかもしれませんが、バグを放置するよりも更新を提供する方がユーザー様のためになるのではないでしょうか。
２．〔仕様〕正規表現本来のregexオプションのs, mを明示的に使用できるようにしてほしい（デフォルトはm）。
[高度] ダイアログの [正規表現「.」が改行コードに一致することができる] オプションがこれ相当します。
3.～10. については検討します。
よろしくお願いいたします。
「バグの出方」とは何のことをおっしゃっているのか、わからないのですが、検索だけでなくすべての機能においてバグは起こってはいけません。
「バグの出方」が何を言っているのか理解できないということは、ソフトウェア開発者に要求されるテストスキルが低くて実践的な実力はほとんどありません。と自白されているのと何ら変わりませんよ。
つまり、バグ（＝不具合）がどの機能にどういうバグ内容で出現しているか、それらを全体として俯瞰したときに、バグそのものが減少傾向にあるのか？または、依然としてバグが出続けているのか？を分析することを指しています。分析とは、バグそのものの重症度、機能別の出現箇所、出現深度（※１）などがどうなっているかを網羅的に把握することです。その分析結果に基づいて、ソフトウェアの品質が高いのか、低いのかを判断して、低いところは改善するための打ち手をいくつか考えて実施する。さらに、高いところは本当に高いのかをさらに疑って、さらにテストパターンを増やして厳しいテストを実施して、本当に品質が高いことを確認する。※１ 出現深度とは、バグの潜んでいる深さを指します。具体的なものはユーザ視点と開発者視点で定義はそれぞれありますが、一般的には、ユーザ視点だとすると、浅い箇所は通常操作でバグが出現する場合、深い箇所は複数の設定などの条件を満たさないと出現しない場合を意味します。私の経験してきたテストでは、言い方は人それぞれありますが、こういことも散々して来ました。
例えば、ソフト開発プロジェクトですと、バグ曲線というグラフを作って、テストケース数の消化率に応じて、バグがどのくらい出ているのかを分析します。そのグラフと検出したバグの内容を考慮して、バグ検出が収束傾向（減少傾向の意）あるかどうか判断して、さらなる打ち手を検討することになります。
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のどのオプションを設定したことになるのかなどを説明を記載してほしい。特に、江村様が実装された検索挙動については、明確にわかるようにヘルプに記載するべきです。
長く書いてしまいましたが、いずれにしても実装却下されたと認識していた追加仕様について、実装を検討されるとの回答でしたので、期待はせずに運が良ければ希望がかなうかもしれない程度に考えておきます。
- このトピックに返信するにはログインしてください。