NotePad++ にある機能で便利だなぁと思ったので要望です。


「上検索」or「下検索」のボタンを押すと
赤枠で囲った「検索」って検索ダイアログの名前?部分が
「検索 XXX件の一致」と変化して件数が表示されると
レイアウト変更しなくて良いかも?と思いました。
一致数が0の場合は「検索 一致せず」が良いでしょうか?(要相談です)
_置換のダイアログでも同じ機能が欲しいと思ってます。_
内部的な話をするとサクラエディタの検索は逐次実行で、最初にすべての検索結果を記憶するわけではありません。それにはレイテンシや記憶領域といった面でメリットがないわけではありません。
Notepad++ は「次を検索」と「数える」を分けていて、arigayas さんの求めている機能は「数える」機能ですよね。分かれているにはやはり理由があります。
で、ならどうするか、は開発者が考えることですが……(安易に要望に迎合しないように気がついたことを書きました)。
実現方法はどうするかはありますが、あったらべんりではありますね。
ただ @ds14050 さんの言う通り、サクラエディタはhtmlファイルだけではなく数ギガのファイルもあつかうので、検索実行して、十数分応答がなくて、何件ヒットしたかをカウントして最初のヒットした文字のところにカーソル位置づいて、何か修正すると、次のヒットはまた全件検索で十数分応答がなくなって^* になりそうなので、参照しかしないファイルだったらよさそうですけどね。
課題共有ってことで。
私の場合は、grepしちゃいますね、この場合。
ds14050 さん
検索数を覚えているわけではないのは、わかりました。
Notepad++ が「次を検索」と「数える」に分けているのには理由があるのも、わかりました。
安易に要望に迎合しないように気がついたことを書きました
確かに(笑)
KENCHjp さん
数ギガのファイルを扱う可能性を考慮していませんでした。
確かにGrepすれば検索数が表示されますね。でも
置換のダイアログでも同じ機能が欲しいと思ってます。
とissue登録コメントに書いたのは、
置換ボタンを押していって後どれくらい件数があるのか
リアルタイムで把握出来たら、ちょっと便利だなぁと思ったのです。
「この要望を取り入れるのが難しい」or「Grepで代用すれば良いじゃない」というのなら
Closeしても構いません。任せます。
任せます。
貴重なご意見ですし要望としては、ありかと思っていますのでcloseしなくてもいいかなと思います。
ブラウザとテキストエディタの違いをうまく考慮してユーザーの利便性を上げるやり方は考える必要ありかと思います。
実装側は言われたまま実装して結局使い物にならない状況にならないようにとの、内部啓蒙を、 @ds14050 さんは言われてたかと思います。
幸い今いる実装メンバーは「そもそもの真の目的はどこにあるのか、その機能を実装することによる弊害はないか」などをよくよく吟味するメンバーがそろってると思っていますので、いい落としどころみつけられるかなともおもうので、要望は要望として存在する価値はあるかと思っております。
全部で何件で、今選択状態にあるのが全体のうちの何件目が表示されるのは確かに欲しい瞬間が私もありますし。
最終的に代替え機能で十分要件を満たせる場合に本件クローズでもいいかなと。
これも、あるのが自然だと思ってます。
コードの作りの都合で直ぐには導入出来ない気がしますが、やりたいと考えています。
いつか追加したい機能の1つということで理解しました!
上検索、下検索というボタンのそれぞれに数が表示されて、上にいくつのマッチ、下にいくつのマッチがあるか、ボタンを押す前にわかると嬉しいです!
5chに書いてあったんですが、カウントする機能を別のスレッドで行うのは難しいのでしょうか?
入力して一定時間経ったタイミングでスレッドを起こして、
検索ヒット件数をカウントさせる実装は可能です。
いまいるメンバーなら実装自体はできると思います。
review を越えられるかどうかが目下の課題なのかな? > #467
下書き中に先を越されてしまった。もったいないのでそのまま投稿します。
私2chに妄想を書きました(笑)
なぜ妄想かというと、構想段階ではいい考えに思えても実際に実装に取りかかると両手では足りない数の問題にぶつかることが常だからです。つまりやってみないと難しいかどうかもわからない、と。
「次を検索」コマンドの実装はエディタの諸部分と結びつきすぎていてバックグラウンドでの実行には向きません。ワーカースレッドを1つ作成して検索条件に変化がある度に検索条件一式としてのダイアログ(+選択範囲+キャレット位置)を受け渡して独自の方法で検索を実行させてマッチカウントを随時フィードバックさせるのはどうかと考えましたが、考えただけです。実際の障害もどれくらい面倒かも見えていません。フィードバック方法が SendMessage か PostMessage かというひとつとってもわからないものなのです。
カウントする機能を別のスレッドで行うのは難しいのでしょうか?
別のスレッドにするのは実装的にはできるとおもいますが、カウントは結果がほしんじゃないでしょうか?
スレッドを分けても終わるまで「人」は待っちゃうんじゃないかと&途中で編集されたらまたスレッド破棄して再実行しなきゃいけないような。
またどう実装するかは @ds14050 さんかかれてますが結構考えること多そうかなと。
検索条件が変わるタイミングで実行中のスレッドを止めるようにしたら、走らせる非同期スレッドを一本だけに出来るかな?と思っています。
スレッドが終わる時は普通にSetWindowTextすれば戻り値いらないはず。
ふわっとした実装検討は始めていて、新規コードよりも既存整備の修正量が多いのが目下の課題です。
スレッドが終わる時は普通にSetWindowTextすれば戻り値いらないはず。
ワークスレッドからは、直接、コントールなどのUI 要素に
直接アクセスできなかったと思うので、情報をUI スレッドに
渡す方法が、要ると思います。
そりゃドットネット…
生apiの場合他プロセスからでさえ通ったりするはず。
検索ダイアログを表示中でもテキストの編集ができるので、
ということも考えました。
検索ダイアログを表示中でもテキストの編集ができるので
検索ダイアログが入力フォーカスを失ったらカウントスレッドを破棄する感じにすれば、メインの編集で同期を取らなくてもよっぽど大丈夫かと思います。
週末に実装検討の経過をあげます。
ややこしいのでコードとか絵とか見て話した方が良さそう。
検索ダイアログが入力フォーカスを失ったらカウントスレッドを破棄する感じにすれば、メインの編集で同期を取らなくてもよっぽど大丈夫かと思います。
アクティブでないときに休止するのはいいですね。バックグラウンドにやって、カウントが終了するのを他のことをして待つ人もいないでしょう、たぶん。
Most helpful comment
上検索、下検索というボタンのそれぞれに数が表示されて、上にいくつのマッチ、下にいくつのマッチがあるか、ボタンを押す前にわかると嬉しいです!