Revert "grep で 除外ファイル、除外フォルダが効かない問題を修正するため、除外パターンを指定するコマンドラインを復活する"

[m-tmatma]

Reverts #750

[beru]

取り消しOKです

[m-tmatma]

sakura-editor/management-forum#60
を検討中なのでもうひとつ approve を待ちます。

[berryzplus]

元に戻す、でOKです。
forumのほうにも書きましたが、やり直ししたとしてコメント書いてapproveにすると思います。
「それだと意味ない」と考えるならこのままでもよいです。

[m-tmatma]

#743 の問題を解決する具体的な方法をお持ちですか？

あらかじめ同じ方法でやり直すのが、確定的なら
意味がないと思います。

別の方法でやるのか、今回の方法でやるのか、
まだ具体的な方法はないけど、少し考えたいというのなら意味はあると思います。

[berryzplus]

#743 の問題を解決する具体的な方法をお持ちですか？

あらかじめ同じ方法でやり直すのが、確定的なら
意味がないと思います。

問題の本質は、コマンドラインからのGrep実行時に、Grepダイアログから実行する場合と同じようにデフォルト設定を取得するようになっていないことだと考えています。

起動方法	説明
ダイアログ	ダイアログ表示時にデフォルトが取得される。変えたいパラメータだけ指定して実行。指定しなかったオプションはダイアログ表示で取得したものが使われる。
コマンドライン	指定したいGrepオプションを漏れなく指定する必要がある。「前回と同じ条件(キーワード＋オプション)」で実行する場合でも全部のオプションを指定しないといけない。

修正箇所は CNormalProcess::InitializeProcess(関数名ちょっと怪しい)なので、このPRにはまったく関係ありません。

つまり、「見方によってはコマンドラインオプションを追加しなかった影響じゃない」んじゃないかな、という見解です。

[m-tmatma]

↑ 修正版の PR 作成は可能ですか？

[berryzplus]

↑ 修正版の PR 作成は可能ですか？

当面課題残しとするつもりです。
PR以前に何が問題なのかissueを立てる必要があると感じていますが、問題の整理ができていません。

[beru]

現状の問題の Issue は #743 で立っていると思います。

問題が起きるメカニズムは、#743 (comment) でコメントしました。

コマンドライン実行の場合にパラメータ指定が必要なのは、そもそもデフォルトの定義が無いからしょうがないと思います。もしデフォルトが欲しければデフォルトの定義をどこかの設定ファイルで決める方法は取れると思います。

仮にデフォルトを追加したとしても、結局GUIで指定した除外ファイルと除外フォルダの情報がコマンドライン実行の場合に使われない問題は本質的には解決しないんじゃないかと思います。

[m-tmatma]

問題の本質は、コマンドラインからのGrep実行時に、Grepダイアログから実行する場合と同じようにデフォルト設定を取得するようになっていないことだと考えています。

問題の本質は、@beru さんが分析されているとおり、最初に起動した sakura.exe のプロセスが
grep ダイアログを表示した後、実際に grep が実行されているプロセスが異なることです。

上記は #756 の PR を作成して、sakura.exe のコマンドラインにファイル名を指定して
起動した後、grep ダイアログを開いて、grep を実行したときの DebugView のログを
確認すると確認できます。

別のプロセスなので、grep ダイアログにユーザーが指定した情報を渡すときに
何からの方法で別のプロセスに渡す必要がありますが、コマンドラインだけで
渡すのなら、新しいコマンドラインで渡すかあるいは既存のコマンドラインに
形に変換して渡す必要があります。

[m-tmatma]

問題の本質は、コマンドラインからのGrep実行時に、Grepダイアログから実行する場合と同じようにデフォルト設定を取得するようになっていないことだと考えています。

これでもいけるんじゃないかと思って revert をマージしましたが、

仮にデフォルトを追加したとしても、結局GUIで指定した除外ファイルと除外フォルダの情報がコマンドライン実行の場合に使われない問題は本質的には解決しないんじゃないかと思います。

このとおりです。

[m-tmatma]

そもそも論ですが、いろいろ踏まえた上で
今もコマンドラインオプションの追加に反対ですか?

[berryzplus]

今もコマンドラインオプションの追加に反対ですか?

yesです。必要ないと思っています。

[m-tmatma]

yesです。必要ないと思っています。

それはなぜですか?

[berryzplus]

なんか論点が違う気がしてます。

除外フォルダ＆除外ファイルの指定がGrep実行に反映されない、という問題は、
PRの一部コミットをrevertしたことにより該当処理が実装漏れになった、ということです。
これについては、本質もクソもないと思ってます。
実装されてないものが動くわきゃないです。

そうじゃなくて、コマンドラインからGrepを実行させようとした場合に、
ダイアログから実行する場合と感覚的に違う動きになることは問題なんじゃないか？
という問題提起が、ぼくが言ってる「本質的な問題」です。

あるフォルダに対して「お茶目」を検索したいとします。
Grepダイアログを開いて「お茶目」と入力してGrepを開始するのがダイアログの操作です。
Grepコマンドのオプションパラメータを全部調べ上げて、漏れなくすべて指定したコマンドラインでenterキーを叩くのがコマンドラインを使う場合の操作です。
※「ダイアログを開くってことはすべてのオプションをチェックするんじゃないの？」と考える律儀な人にとっては、両者の操作は同じになるのかも知れません。

[berryzplus]

yesです。必要ないと思っています。

それはなぜですか?

たぶん #403 で回答したのと同じ理由になると思うんですが。

除外フォルダ＆除外ファイルのパターン仕様は元からあるものだからです。
既存のコマンドラインで実現できないならば増やす意味があると思います。
既存のコマンドラインで実現できることに別のやり方を増やす意味がよく分らないです。

「UIで簡単に指定できるようにする」というエントリユーザ向けの話題と、
「コマンドラインで簡単に指定できるようにする」というマニア向けの話題は別だと思います。
前者については同意で、後者については必要があるか疑問です。

[m-tmatma]

本質的 の定義が違うのかもしれませんが、
#743 という不具合が発生した原因はメインのプロセスから grep を実行するプロセスに情報の受け渡しを行う際に、適切に情報をわさなかったことが、不具合の根本原因です。

その上で、そもそも別プロセスで grep しないようにするなど、複雑な構成に
なっているという構造的な問題を解決したいというのはそれでありだと思います。

たぶん #403 で回答したのと同じ理由になると思うんですが。

確認したいのはコマンドラインで指定したら、#743 の不具合を解決するのは
簡単にできるのに、なぜ反対するか? です。

また、別にやり方は一つでなくてもいいとは思いますし、
既存のコマンドラインはエントリーユーザーには使うのが難しくても
新しいインターフェースだと、エントリーユーザーでも使ってみようかと
思うほどシンプルだと思います。

機能自体は別ですが、例として正規表現やEXCELのマクロは同様だと思います。

正規表現も同様に使うのに知識がいる複雑な機能ですが、エントリーユーザーでも
簡単な使い方がわかれば、一度使ってみれば便利だなと思う機能の一つだと思います。

同様に EXCEL でも中級のユーザーは VBA のマクロを使っています。

上級者とエントリーユーザーと両極端にわかれているわけではなく
その中間のユーザーも存在すると思います。

[beru]

たぶん #403 で回答したのと同じ理由になると思うんですが。

除外フォルダ＆除外ファイルのパターン仕様は元からあるものだからです。
既存のコマンドラインで実現できないならば増やす意味があると思います。
既存のコマンドラインで実現できることに別のやり方を増やす意味がよく分らないです。

つまり berryzplus さんがおっしゃってるのは、除外ファイルと除外フォルダのパターン仕様（パターン先頭に ! や # を付けたり）は元からあるもので既存のコマンドラインのオプションでも実現出来るんだから、新たに GEXCLUDEFILE と GEXCLUDEFOLDER のオプションを増やさない方法で実現するべき、って事でしょうか。

自分はそれでも良いと思います。ただ問題はだれがそれを実装するか、、ｺﾞｸﾘ…。

[berryzplus]

確認したいのはコマンドラインで指定したら、#743 の不具合を解決するのは
簡単にできるのに、なぜ反対するか? です。

新しいコマンドラインオプションをついでで決めていいとは思えないからです。
既存コマンドラインオプションの改廃を含めた検討を行うのであれば、意味がないとは思ってません。

また、別にやり方は一つでなくてもいいとは思いますし、

個人的には複数のやり方があるのを許容しますが、
やり方が2つ以上あるのは混乱の原因になることもあると思います。

既存のコマンドラインはエントリーユーザーには使うのが難しくても
新しいインターフェースだと、エントリーユーザーでも使ってみようかと
思うほどシンプルだと思います。

「既存のコマンドラインは使うのが難しい」です。
なんで難しいんでしょうか？

独自文化すぎて「こうすればOK」の予想がつかないからだと思っています。

では、その基準に照らして新規のオプションって分かりやすいでしょうか？

「見れば分かる」という意味での分かりやすさは満たしていると思います。
「こうすればOKの予想が付くか？」というとビミョーだと思っています。
じゃあどうしたら分かりやすくなるんだろう？無理なの？どうなの？・・・その辺を話し合ってから決めてもよかったんじゃないかと思っています。

[beru]

そうじゃなくて、コマンドラインからGrepを実行させようとした場合に、
ダイアログから実行する場合と感覚的に違う動きになることは問題なんじゃないか？
という問題提起が、ぼくが言ってる「本質的な問題」です。

どうやったら感覚的に同じ動きになるのかは謎ですが、もっと大きく捉えるとコマンドライン側の操作感を向上させたいという事でしょうか？

• オプション指定しなくてもデフォルトで入る設定値を用意 (Revert "grep で 除外ファイル、除外フォルダが効かない問題を修正するため、除外パターンを指定するコマンドラインを復活する" #753 (comment) でコメント有り)
• シェルを変える
• PDCurses 使って操作性上げる
• 指定が楽になる便利なコマンドラインのオプションを増やす

等が思いつきます。

いやしかしこの話題って不具合をどうやって直すか、っていう問題に対する直球ではないと思います。
もしコマンドラインのGrepを違った形で良くしたいのであれば別Issue立ててやった方が良いんじゃないかなと思います。

[m-tmatma]

「既存のコマンドラインは使うのが難しい」です。
なんで難しいんでしょうか？

まず、先頭に ! をつけるというのと # をつけるという仕様を知ったとして
どちらがフォルダに対するパターンか、どちらがファイルに対するパターンが
ドキュメントを見ずに判別することができません。

個人的には複数のやり方があるのを許容しますが、
やり方が2つ以上あるのは混乱の原因になることもあると思います。

ユーザーが使いたい方法を使えばいいと思いますし、
過去に公開した機能を削除しないのは上位互換性を確保する上で重要です。

[beru]

「既存のコマンドラインは使うのが難しい」です。
なんで難しいんでしょうか？

独自文化すぎて「こうすればOK」の予想がつかないからだと思っています。

では、その基準に照らして新規のオプションって分かりやすいでしょうか？

「見れば分かる」という意味での分かりやすさは満たしていると思います。
「こうすればOKの予想が付くか？」というとビミョーだと思っています。
じゃあどうしたら分かりやすくなるんだろう？無理なの？どうなの？・・・その辺を話し合ってから決めてもよかったんじゃないかと思っています。

なんかこの話って結構長く続いていますが、berryzplus さんの代案は結局何なんでしょうか？

[m-tmatma]

既存コマンドラインオプションの改廃を含めた検討を行うのであれば、意味がないとは思ってません。

昔の話を持ち出して悪いんですが、
#419 (comment)

で以下のようなコメントを書いておられます。

コマンドラインオプションは、他プログラムとの連携で使えるものです。
システム開発の業界用語で言うと「外部I/F仕様」の一部になります。
一般的に外部I/F仕様は、内部設計の都合で変えてよいものじゃないと思います。

「コマンドラインオプション」が外部仕様なら、既存のオプションはそもそも廃止したらいけないように思います。これは ver 2.4.0.0 以前と以降の sakura.exe を起動する場合で呼び出し側でバージョンチェックしてどちらのやり方でもできるように、ユーザー側で対処する必要があるためです。

いまいち反対の理由が腑に落ちないです。

なにか、これは当然だと思って話しているど、まだ話していないものとかありますか?

一番最初から今までの議論の中で反対の理由が、ぶれているように感じます。
最初は気づいていなくていろいろ議論している中で気づいたというのならいいんですが。

[berryzplus]

@beru さん

なんかこの話って結構長く続いていますが、berryzplus さんの代案は結局何なんでしょうか？

既存仕様で対応すればいい、です。
コマンドラインを追加しなくても対応できるじゃん、ということを言い続けてます。

[m-tmatma]

1. 既存仕様よりも、新しいコマンドラインオプションの方が使いやすいという点は同意ですか?

既存仕様で対応すればいい、です。
コマンドラインを追加しなくても対応できるじゃん、ということを言い続けてます。

2. 既存仕様で対応するメリットって何でしょうか?
   新しいコマンドラインオプションを追加する場合と比べた場合の優位性がよくわかりません。
   理論的に可能、というのとそれが望ましい解決策というのはまた別だと思います。
   既存機能の枠組みで対応した場合、誰にとってメリットがあるのでしょうか?
   そこを教えてください。

個人的には複数のやり方があるのを許容しますが、
やり方が2つ以上あるのは混乱の原因になることもあると思います。

3. それはドキュメントの説明が不足しているからですか?
   ２つ以上方法があってもこのバージョン以降ではこちらの方法が推奨です、
   とドキュメントに記載すればいいだけのように思います。

「こうすればOKの予想が付くか？」というとビミョーだと思っています。

4. これは意図するところがわからないです。
   どういうことか教えていただけますか?

じゃあどうしたら分かりやすくなるんだろう？無理なの？どうなの？・・・

5. わかやすくなるというだろうという提案はすでにしており、実装しています。
   具体的にどの部分がわかりにくいですか?

その辺を話し合ってから決めてもよかったんじゃないかと思っています。

7. 話し合うというよりも具体的な提案あるいはPRをしていだきたいです。

[berryzplus]

既存コマンドラインオプションの改廃を含めた検討を行うのであれば、意味がないとは思ってません。

議題を変えたら主張のアプローチを変えるのは当然です。

「既存のコマンドラインの仕様が難しすぎてよく分らない」の対策を考えるなら
「じゃ、コマンドラインの仕様を考え直そう」という発想が出てくるのは普通だと思います。
実際に「じゃ、廃止しよう、廃止～！」とするかどうかは別の話です。

コマンドラインオプションを分かりやすくするために、他ツールのオプションを参考にして新たなオプション体系を作り上げることは有意義だと思います。

最終的には、前に書いたのと同じ理由で「既存オプションは廃止すべきじゃない」と結論付けると思います。重要なのは、その結論に至るまでの過程だと思っています。

なにか、これは当然だと思って話しているど、まだ話していないものとかありますか?

結局のところ「コマンドラインの仕様が難しい」に同意できてないんです。

他人に理解してもらうのが難しいので「難しい」と表現してきましたが、
個人的にはシンプルで分かりやすい仕様だと思っています。
さんざん「難しい」言っといて「俺にとっては簡単よ」とかいうと
なんか「何様？」な感じになるので言えませんでした。

• パターンは「 」か「;」か「,」区切りで複数指定できる
• パターンの先頭に「#」を付けると除外したいフォルダ名を指定できる
• パターンの先頭に「!」を付けると除外したいファイル名を指定できる

このシンプルな仕様の何がそんなに難しいのか理解できとらんのです。

仕様を理解できているなら、コマンドラインに渡す「ファイル」にUIから取得した文字列を組み込んで渡すのはたやすいはずです。新たなオプションを追加しなくてもよいと思います。

前にこの話をしたら、こんな難解なうんこ仕様を未来に残すのはよろしくない、と反論された気がします。もちろん理解できませんでしたが「分かりました」と書いた気がします。あの状況で、シンプルで分かりやすい仕様だと思う、とは書けませんでした。

現状のコマンドライン仕様が一般の人にとって難しいのであれば、対処はしたいです。
ただ、この仕様が開発者にとって理解できないくらい難しいかというと違うと思います。

ぼくらは開発者なので、多少難解な仕様であったとしても、
それらを読み解いて実装してやるのが正しいあり方だと思ってます。

このパターン指定の仕様、本当に難しいと感じていますか？
（もちろん、「今でも」という意味で。

[berryzplus]

1.既存仕様よりも、新しいコマンドラインオプションの方が使いやすいという点は同意ですか?

すでに書きましたがビミョーだと思います。

2.既存仕様で対応するメリットって何でしょうか?
新しいコマンドラインオプションを追加する場合と比べた場合の優位性がよくわかりません。

外部仕様を変えないことができる、です。
一度変更した外部仕様は基本的に変更できません。

既存機能の枠組みで対応した場合、誰にとってメリットがあるのでしょうか?
そこを教えてください。

サクラエディタのユーザにとって、ですね。

3.それはドキュメントの説明が不足しているからですか?

違います。単なる一般論です。

「こうすればOKの予想が付くか？」というとビミョーだと思っています。
4.これは意図するところがわからないです。
どういうことか教えていただけますか?

オプションを同種の他ツールと同じにしたら「サクラエディタの独自オプション」を新しく覚えなくても他ツールの利用経験があれば対応できます。たとえばvimに合わせる、というのが候補です。合わせる先をvimにするかどうかはそういう議題で話すときに詰める話ですが。

うしたら分かりやすくなるんだろう？無理なの？どうなの？・・・
5.わかやすくなるというだろうという提案はすでにしており、実装しています。
具体的にどの部分がわかりにくいですか?

たとえば linux の grep コマンドには除外ファイルのオプションがありますが、追加した新規オプションは完全独自になっています。同種の他ツールの使用経験がサクラエディタでは活用できない感じになっています。

7.話し合うというよりも具体的な提案あるいはPRをしていだきたいです。

残念ながらぼくの中でこの件の優先度はあまり高くありません。
具体的な提案は上に少し書いてみました。

[m-tmatma]

最終的には、前に書いたのと同じ理由で「既存オプションは廃止すべきじゃない」と結論付けると思います。重要なのは、その結論に至るまでの過程だと思っています。

勘違いされていますが、
一度も 「既存オプションを廃止」 を提案したことはありません。
既存機能を保持した上で新規オプションを追加するものです。

7.話し合うというよりも具体的な提案あるいはPRをしていだきたいです。

残念ながらぼくの中でこの件の優先度はあまり高くありません。
具体的な提案は上に少し書いてみました。

過去はそうでした。
しかし、現在は #743 という問題が発生することはわかっています。

この問題が解決するまではリリースできないと考えています。
現在はリリースブロッカーという認識です。

なぜなら、一般的なユーザーが十分遭遇するユースケースだからです。

既存機能の枠組みで対応した場合、誰にとってメリットがあるのでしょうか?
そこを教えてください。

サクラエディタのユーザにとって、ですね。

どういう属性のサクラエディタユーザーですか?
具体的にどのような理由で、メリットになるのでしょうか?

このシンプルな仕様の何がそんなに難しいのか理解できとらんのです。

#752 (comment) には
元々、仕様がかなりややこしいんです。 と書いています。
このコメントと上記のコメントは矛盾しているように思います。

わかりやすいのか、わかりにくいのかどっちやねん、と言いたいです。

[m-tmatma]

ぼくらは開発者なので、多少難解な仕様であったとしても、
それらを読み解いて実装してやるのが正しいあり方だと思ってます。

根本的なところの考え方が違うのかもしれませんが、

まず、何かの規格に対応する場合等自分たちで仕様を決めることができない場合には
多少難解な仕様であっても頑張って実装する必要があります。

しかし、自分たちで自由に仕様を決めることができる場合に関しては
実装やメンテナンスの容易さ、ユーザーの使い勝手等を総合的に判断して
最もシンプルに作るものだと思います。

現状のコマンドライン仕様が一般の人にとって難しいのであれば、対処はしたいです。
ただ、この仕様が開発者にとって理解できないくらい難しいかというと違うと思います。
このパターン指定の仕様、本当に難しいと感じていますか？
（もちろん、「今でも」という意味で。

別に私自身が理解できないと言っているわけではないです。
仕様を理解した上で grep の除外パターンを別に指定できるように拡張する PR を投げました。

コマンドライン仕様は別に開発者だけが使うものではありません。
コマンドラインという指定の仕方ができるんだ、ということに気づいた中級以上の
ユーザーなら誰でも使うことができるものです。

そういうユーザーがいたときに現在の仕様はそういうユーザーに取ってシンプルで
わかりやすい仕様になっていないと考えています。(#752 で @beru さんが勘違いしたように)

繰り返しになりますが、多少難解な仕様 はどういうふうにユーザーに取って
メリットがあるのですか?