Grep機能のうち、いくつかの機能を思い切って削除してはどうでしょうか?という提案です。
既存機能を削除することは、その機能を使っているユーザーにとっては迷惑な仕様変更であることは理解しています。
ただし、下記メリットも存在しますので一考いただければ幸いです。
・ユーザーの使いやすさ向上(UI改善)
→あまり使われない機能がごちゃごちゃとあるとぱっと見での使いやすさが低下します。
→他エディタからの乗り換えor新規ユーザーでも直観で使えるUIとしたいです

・開発速度の加速
→ご存じの通り(?)現在のサクラエディタのGrep周りの実装はかなりカオスな状況になっています。
→その結果、古参メンバー以外が手を入れれる状況ではないです。
→削除できる機能であれば削除したほうが今後のメンテナンス性が向上します。(製品の場合、実装がカオスな状況に対しての手段としては不適かもしれませんが、OSSとしてはありだと思います)
→また、開発速度が加速することで間接的にユーザーにとってもメリットがあると考えています。
Grep検索画面のうち、個人的に不要と思っている機能を列挙します。
下記は私の周りの人で使っている人も見たことがありません。
・現在編集中のファイルから検索
・ファイル毎最初のみ検索
下記も個人的には不要だと思っておりかつ、少なくともGrep検索画面にはかなり不要と思っている機能です。
もし必要であれば共通設定の検索タブに移動しても良いと思っています。
・フォルダ毎に表示
・ベースフォルダ表示
・フォルダの初期値をカレントフォルダにする
・結果出力
・結果出力形式
まずは開発コアメンバーの皆さんに、Grep機能の一部機能を削除することに関しての是非を聞きたいです。
現在編集中のファイルから検索 はたまに使いますが必ず必要かというとそんな事は無いと思います。ファイル名指定すれば良いだろうし。ファイル欄に変数名指定で現在編集中のファイルの指定が出来ると良いですね。
使用頻度が少ない設定は別のモーダル表示のダイアログに移すとかも手かもしれないですね。
簡易表示・詳細表示の切り替えボタンがあるといいかもしれません。
はGrepしてどのファイルに「検索した文字列」があるのか無いのか知りたい時に使ってます。
1ファイルの中に数十箇所該当する場合にスキップできるのでちょっと欲しい機能です。
意見を聞いて
・現在編集中のファイルから検索
・ファイル毎最初のみ検索
は検索方法として確立しているので、消すというよりかは
使用頻度が少ない設定は別のモーダル表示のダイアログに移すとかも手かもしれないですね。
か
簡易表示・詳細表示の切り替えボタンがあるといいかもしれません。
の手段で基本画面からは隠す方向がいいのかなと思いました。
下記はGrep結果の表示方法の変更なので機能的に必須かと言えば不要な気がしますので、特に意見が無ければ削除PRを出す予定です。
・フォルダ毎に表示
・ベースフォルダ表示
・結果出力形式
・結果出力
も、該当行モード以外をつかうシチュエーションが思いつかないです。
Grep検索画面のうち、個人的に不要と思っている機能を列挙します。
下記は私の周りの人で使っている人も見たことがありません。
・現在編集中のファイルから検索
・ファイル毎最初のみ検索
「ファイル毎最初のみ検索」は私は使うことはないですが、
「現在編集中のファイルから検索」は結構いっぱい使います。
も、該当行モード以外をつかうシチュエーションが思いつかないです。
@7-rate さんが使い方を思いつかないというのだけでは
これは全然根拠としては足りないと思います。
「現在編集中のファイルから検索」でこの issue で提案しただけで使っている人がいました。
以前
https://github.com/sakura-editor/sakura/issues/733#issuecomment-451040701
でそうする場合は 「my_icons.bmp 等を sakura.exe と同じフォルダに入れたらそれが
使われるという機能」を削除するしかないんじゃないみたいな話になりました。
当時開発メンバーで使ってる人の話はでませんでしたが、
https://github.com/sakura-editor/sakura/issues/1243 にあるとおり使っている人がいました。
機能として削除するという話と使い勝手をよくするために見た目をすっきりさせる
というのは全く別の話です。
・開発速度の加速
→ご存じの通り(?)現在のサクラエディタのGrep周りの実装はかなりカオスな状況になっています。
→その結果、古参メンバー以外が手を入れれる状況ではないです。
→削除できる機能であれば削除したほうが今後のメンテナンス性が向上します。(製品の場合、実装がカオスな状況に対しての手段としては不適かもしれませんが、OSSとしてはありだと思います)
→また、開発速度が加速することで間接的にユーザーにとってもメリットがあると考えています。
カオスなコードに対して、多少のオプションを削ったところでカオスの状況に変わりはなく
メンテナンス性が向上するところまで行くのであれば再設計してスクラッチから書くとかしないと
単に機能が減っただけで、かつ、削除した後のコードがちゃんと動作するためにテストしないといけないのでメリットがないように思います。
例えば、既存機能を残したうえで実験的な実装として、スクラッチで新しいコードを実装して新しいコードが安定した時点で古いコードを引退させるとかするならいいのですが。
出遅れた。。。orz
「ファイル毎最初のみ検索」は私は使うことはないですが、
「現在編集中のファイルから検索」は結構いっぱい使います。
全面同意です。
vs2017使ってる時でもフォルダ検索で対象を「現在のドキュメント」にしたりします。
「ファイル毎最初のみ検索」は用途次第ですが、
それが必要なときはubuntuにブチ込んでリアルgrepしちゃう派です。(身も蓋もねぇ・・・
@7-rate さんが使い方を思いつかないというのだけでは
これは全然根拠としては足りないと思います。
サクラエディタのコアユーザーって、ある意味「変態の旦那方(≒もの好き)」なので、「普通に考えて」削除提案をすると闇討ちにされる危険があると思います。
ここぞとばかりに「まだその域に達していない」って言われるんですよ、きっと。
さて、進撃の巨人ネタはこれくらいにして。
CGrepAgent::DoGrep の実装に絞って話をします。
この関数がカオスな理由は、これの役割が不明瞭だからです。
役割は、引数で指定された情報からGrepを実行して、
引数で指定された何か(=コンソール or エディタビュー)に
Grep結果を WriteLine することだと思います。
そういう目線でコード読んでみてください、言ってる意味が分かるかもしれません。
ちょっと待て、それ以外の処理が大量に入りこんでいるじゃないか!
そう、だからカオスに見えるんだと思います。
課せられた役割に対して、明らかに無関係な処理が入りこんでいます。
Grepを実行して結果を出力する処理に、なんで「アイコンの設定」が混じっているのか。
Grepを実行して結果を出力する処理に、なんで「Undo処理」が混じっているのか。
Grepを実行して結果を出力する処理に、なんで「ビューの再描画」が混じっているのか。
たぶん、それぞれそれなりに納得できる当時の事情があったんだと思いますが、全体をざっくり把握した目でみると「なんでやねん!」の嵐です。だから、カオスに見えるんだと思います。
私には最初に書いた以上の説得材料はないため削除は無しという方向で、このissueは閉じます。
使い勝手を良くするためのUI変更については、(もちろん変更方法によるとは思いますが)大筋として意義無しと認識しました。余裕とやる気が出た時にPRさせていただきます。
オフトピですが
大筋として意義無しと認識しました。
「意義無し」って「異議無し」の間違いでしょうか?
同音異義語の罠ですね。
意義なし(=それ削られたら困るのでヤメテ!)
異議なし(=余分なものなら削ったらええんちゃう?)
どちらも「大筋で」に合ってる気が・・・ :smile:
日本語ムズカシイ・・・。
そしてMS-IMEよりマシなFEPを求めてTSF対応模索の長い旅が始まるのでした・・・。