大量の文字を範囲選択してからの検索関連の動作が重い
-
サポートお疲れさまです。(リリース直後ゆえか最近は少しにぎやかですね)
以下の状況に遭遇したため、ご報告します。
Mery x64 ver 3.6.2
Windows 11 22H2 22621.2506(1)
改行を多く含む範囲を選択中に検索ウィンドウを表示すると動作が重くなるようです。以下のように数千行の改行含む範囲を「選択 → 検索 or 置換ウィンドウ表示」とすると、表示されるまで4,5秒ほどかかります。
対象となる行数を増やせば増やすほど時間がかかるようです。a b c ... 以降、2000行程度まで繰り返す現状、選択文字数が43680文字以上になっていると検索文字列として反映されないように制限されているようですので、改行文字も特定数以上入っていたら検索文字列として反映しないような制限があった方がよさそうです。
・上記現象に遭遇するケース1: 選択した範囲のみ検索／置換 をしたい場合の操作として、大量行選択→検索ウィンドウ表示 をするときの表示が遅くなる
・上記現象に遭遇するケース2: ケース1などの操作によって1度検索文字列に大量の改行文字が含まれてしまうと、次に未選択状態で検索ウィンドウを開いたときに前回の検索文字列として初期表示されてされてしまうため、検索ウィンドウの表示が遅くなる(2)
上記を検証している最中に気づいたのですが、検索中の文字数が多いときに自動マーカーの動作が遅くなるようです。aaaaaa ... 以降、43679文字になるまで繰り返す1. 上記のように43679文字の「a」をすべて選択し、検索ウィンドウを表示
2. 検索文字列として43679文字の「a」が表示されている状態で検索実行
3. 適当な文字を範囲選択する →範囲が広がるたび自動マーカーが動作、コンマ数秒の遅延を感じる※2で検索実行さえしなければ自動マーカーが遅くなることはない
察するに、ハイライトのために通常の検索 (43679文字の検索) も動いていそうで、そうすると仕様上仕方ない気もしているのですが、ひとまずご報告しておきます。
| yuko | 返信 -
> 改行文字も特定数以上入っていたら検索文字列として反映しないような制限
こちら、念のため希望を…
制限については、序盤の数行だけ検索文字列に入るよりかは検索文字列クリアの方が分かりやすいと思うので、クリア動作が希望です。(現状の43680文字以上の選択のときのクリア動作と同じ)ちなみに、43679文字の改行なし文字列の場合には検索ウィンドウ表示の際の重さは感じませんでした。
| yuko | 返信 -
> サポートお疲れさまです。(リリース直後ゆえか最近は少しにぎやかですね)
ありがとうございます。そのようですね😭 今のところ大きな問題は発生していないようですし、修正が大変ってことはないですが、サポート件数が多いと時間が足りないですね。
時給でも出ないとやってられないッス😵💫 などと、心の声を漏らしつつ、ご報告ありがとうございます。
> (1)
> 改行を多く含む範囲を選択中に検索ウィンドウを表示すると動作が重くなるようです。確認しました。特に、43680 文字で制限をかけているわけではないのですが、Windows のコンボ ボックスの限界なのかもしれないです。
改行を含まない場合でも「aaaa....」は大丈夫ですが、「ああああ....」だと重くなりました。
そこで、文字数の制限はどれくらいが適切なのか、他のエディターでも確認してみました。
・秀〇エディタさん: 半角 16381 文字、全角 8190 文字
・E〇Editor さん: 43680 文字 (Mery と同様、重くなる)
・サク〇エディタさん: 43680 文字 (重くならない)
・Windows 10/11 のメモ帳: 127 文字 (超える場合は最初の 127 文字のみ)
・ワードパッド: 127 文字 (超える場合はクリアされる)
・VSCode: 制限なし？
・Visual Studio 2022: 制限なし？
・Sublime Text: 制限なし？サク〇エディタさんは制限なし (43680 文字) なのに重くならないなーと思って、調べてみたところ、どうやら、フォントが関係しているようです。
Mery でも検索ダイアログを MS ゴシックに変更すると「ああああ....」は問題ありませんでした。メイリオのような、滑らかなフォントの場合、「全角文字」の描画がボトルネックになっているような気がします。
ただし、「改行文字」を含む場合はフォントに関係なく重くなるようです。
> (2)
> 上記を検証している最中に気づいたのですが、検索中の文字数が多いときに自動マーカーの動作が遅くなるようです。これはご推察のとおり、自動マーカーは対象となる行を再描画するので、大きな文字列で検索した状態だと、ハイライト表示の検索も同時に実行されますから、検索速度の影響を受けてしまいますね。
こちらは仕様上、どうすることもできなさそうですが、(1) の対応として、検索文字列の長さに制限を設けるようにすれば、影響は少なくなるかと思います。
> 制限については、序盤の数行だけ検索文字列に入るよりかは検索文字列クリアの方が分かりやすいと思うので、クリア動作が希望です。
そうですね。制限を設ける場合、文字数については実機で動作速度を計測したりなどの検証が必要になりそうです。(秀〇エディタさんの 8000 文字あたりが安全圏な気もしますが)
また、制限を超えた場合の仕様については、クリア動作の方向で検討してみますね。
| Kuro | 返信 -
> 時給でも出ないとやってられないッス😵💫 などと、心の声を漏らしつつ、ご報告ありがとうございます。
そうですよねー (とか言いつつ、賑やかしの一人になってしまってすみませんｗ)
これまた色々と検証いただきまして、ありがとうございます。
フォントの問題で遅くなるとは、これまたレアな事象ですね。
MSゴシックのようなビットマップフォントはヒンティング処理がまったくかからない特性がありますから、描画負荷が低いとか、そういうことがあるんでしょうかね。今改めて動作を眺めてみたのですが、43679文字が入力された状態で1文字でも入力すると、パッと表示がクリアされたような挙動をします。ただし内部的には入力内容を保持しているようで、追加した分を消してまた43679文字まで減らすと再度表示されるという、なんとも絶妙な動きになっていました。
さすがにこれから自前で制限を入れるとなったときには上記のような動作にはならないと思いますが、以下のような動きになってくれると嬉しいです。
(仮に10000文字を検索文字列の文字数上限として)
・10000文字を選択し検索ウィンドウ表示
→選択文字列がすべて検索文字列として表示される
・10001文字を選択肢検索ウィンドウを表示
→検索文字列は空で表示される
・10000文字未満を選択して検索ウィンドウを表示。そして追加で入力して10001文字以上入力しようとする
→10000文字目は入力される。10001文字目以降は入力できない (10000文字目までで入力がストップする形)。あるいは「10000文字以内で入力してください」とアラート出してクリアしてしまってもよさそう。| yuko | 返信 -
> そうですよねー (とか言いつつ、賑やかしの一人になってしまってすみませんｗ)
いえいえ、全然問題ありません～。yuko さんもフリーソフトを公開されていらっしゃるので、こっち側だと思ってますw👍 それに、不具合報告は大歓迎ですからね😊
> MSゴシックのようなビットマップフォントはヒンティング処理がまったくかからない特性がありますから、描画負荷が低いとか、そういうことがあるんでしょうかね。
描画時のひどいチラつきを見る限りでは、その可能性はありそうですね。
> 今改めて動作を眺めてみたのですが、43679文字が入力された状態で1文字でも入力すると、パッと表示がクリアされたような挙動をします。
検証までしていただき、ありがとうございます。なるほど、そのパターンまでは考慮していませんでした。
> (仮に10000文字を検索文字列の文字数上限として)
> ・10000文字を選択し検索ウィンドウ表示
> →選択文字列がすべて検索文字列として表示されるはい、そうなりますね。
> ・10001文字を選択肢検索ウィンドウを表示
> →検索文字列は空で表示されるはい。私も、その仕様が好ましいかと思います。
> ・10000文字未満を選択して検索ウィンドウを表示。そして追加で入力して10001文字以上> 入力しようとする
> →10000文字目は入力される。10001文字目以降は入力できない (10000文字目までで入力がストップする形)。あるいは「10000文字以内で入力してください」とアラート出してクリアしてしまってもよさそう。Windows のコンボ ボックスの標準機能でできるのは、入力がストップするほうですね。
手動で入力する場合、秀〇エディタさんとサク〇エディタさんの両方、30000 文字で入力がストップするようです。
サク〇エディタさんでは、43679 文字を選択して Ctrl + F を押すと、なぜか 30000 文字を超えて入力されるようですが、それ以上の入力はできませんでした。
また、制限を超えた文字数をコピペした場合は、30000 文字で切られる感じになります。
ただ、私の環境では 10000 文字程度でもダイアログがそこそこ重くなるので、何か他に速度改善の方法がないかという側面からも調査してみようと思います。
| Kuro | 返信 -
> Windows のコンボ ボックスの標準機能でできるのは、入力がストップするほうですね。
なるほど、であれば手軽な制限方法がちょうど想像している動作ということで、安心しました。
描画ということで環境の性能差はありそうですが私の環境では10000文字「あ」でも特に重さは感じませんでした。
ただ改行が含まれると重くなる現象の方はたった1000行でも検索ウィンドウ表示時にかなりラグいので、文字列長全体での制限の他に、改行含む選択の場合には改行の数でも制限があった方がいいかもしれません。
秀丸は、そもそも複数行選択 (ただし次の行先頭にカーソルがある場合は単行扱い) のときには検索文字列がクリアされる仕様なようですね。
というか今更知ったのですが、秀丸は検索文字列のテキストボックス横の ▶ を展開すると、検索文字列に改行入力ができるんですね。また、もう一度 ▶ を押すと複数行の選択範囲を取り込むようにしているようです。
これに続けて、改行を入れた複数行入力ボックスを解除すると1行のテキストボックスに戻るのですが、戻ったあとは独自の空白風グリフ？に見た目が変換されるようです。これで動作遅延を回避していたりするのだろうか…🤔| yuko | 返信 -
> 描画ということで環境の性能差はありそうですが私の環境では10000文字「あ」でも特に重さは感じませんでした。
あらら、そうでしたか。
私の環境ですと、秀〇エディタさんは 30000 文字の「あ」でもそこそこ軽かったもので、何か高速化の技術があるのかも？と、思い調査していたのですが…
結論として、フォントが影響していました。
秀〇エディタさんはコンボ ボックスのフォントがエディター部分のフォントと連動しているようで、私の環境では「メイリオ」を使用していました。そこで、Mery でも「メイリオ」にしてみたら、「あ」はそこそこ軽くなりました。
> ただ改行が含まれると重くなる現象の方はたった1000行でも検索ウィンドウ表示時にかなりラグいので、文字列長全体での制限の他に、改行含む選択の場合には改行の数でも制限があった方がいいかもしれません。
そのようですね。他の速度改善の方法も調査しましたが、これ以上の改善は難しいようで、改行の数にも制限を設けるのが良いかもしれません。
> 秀丸は、そもそも複数行選択 (ただし次の行先頭にカーソルがある場合は単行扱い) のときには検索文字列がクリアされる仕様なようですね。
そうですね。Mery でも以前はその仕様だったのですが、ご要望により、Ver 3.4.0 で改行を含めるように仕様変更してますね。
> というか今更知ったのですが、秀丸は検索文字列のテキストボックス横の ▶ を展開すると、検索文字列に改行入力ができるんですね。また、もう一度 ▶ を押すと複数行の選択範囲を取り込むようにしているようです。
そうなんですよね。Ver 3.4.0 の開発時に調査しましたが、そのとき、フォーラムでは秀〇エディタさんのような「複数行入力」まではサポートする必要がないだろう、というご意見をいただき、現在の仕様に至りました。
【検索、置換で改行を含む文章が選択できません】
https://www.haijin-boys.com/discussions/6826> これに続けて、改行を入れた複数行入力ボックスを解除すると1行のテキストボックスに戻るのですが、戻ったあとは独自の空白風グリフ？に見た目が変換されるようです。これで動作遅延を回避していたりするのだろうか…🤔
秀〇エディタさんのテキスト ボックスのフォントは、エディター部分で設定しているフォントに連動するようなので、空白風のグリフというのはフォントに依存するのかもしれません。
ちなみに、私の環境ですと、複数入力ボックスを解除して 1 行のテキストボックスに戻すと、普通に重くなってしまいます。
| Kuro | 返信 -
> そうなんですよね。Ver 3.4.0 の開発時に調査しましたが、そのとき、フォーラムでは秀〇エディタさんのような「複数行入力」まではサポートする必要がないだろう、というご意見をいただき、現在の仕様に至りました。
そういえば、割りと最近の仕様からでしたね。(とはいってももう1年も経っていたのね・・・)
私も改行付き検索はほとんど行わない (やるとして正規表現を使う) ので、 UIとしての複数行入力の対応への希望は無いのですが、もし改行付き検索文字列を入力するにあたって軽くなるといったことであれば利便性だけでなく高速化という理由も出てくるので、一考の余地ありかもしれません。
とはいえ前述の通り、改行付き検索をほとんどやらないので、普通に制限を設ける方式であっても個人的には十分ですがｗ
> 秀〇エディタさんのテキスト ボックスのフォントは、エディター部分で設定しているフォントに連動するようなので、空白風のグリフというのはフォントに依存するのかもしれません。
>
> ちなみに、私の環境ですと、複数入力ボックスを解除して 1 行のテキストボックスに戻すと、普通に重くなってしまいます。肝心の、1行にテキストボックスを戻したときの重さ具合を見ていなかったです😅ｗ
こちらでも3万行の「あ\n」な文字列を1行に戻したところ、重くなりました。また、空白風のグリフというのは、仰るとおりフォント依存でした。UDEV Gothicを設定していたのですが、どうやらJetBrains Mono由来でCR (U+000D) に半角幅の空グリフが設定されていたようです。(知らなかった)
https://imgur.com/a/BeYK9j8| yuko | 返信 -
ご確認いただき、ありがとうございます。
空白風グリフの件と、秀◯エディタさんでも性能低下が起こったことから、コンボ ボックスの仕様によることが分かり、少し気が楽になりました。
> とはいえ前述の通り、改行付き検索をほとんどやらないので、普通に制限を設ける方式であっても個人的には十分ですがｗ
通常、改行を含む検索文字列は最大でも 1、2 個程度かと思われます。1000 個の改行を含む検索文字列となると誤操作の可能性が高いでしょうね。
> もし改行付き検索文字列を入力するにあたって軽くなるといったことであれば利便性だけでなく高速化という理由も出てくるので、一考の余地ありかもしれません。
そうですね。個人的な興味としては、あの UI で使用されている複数行入力できるコンボ ボックスのほうが気になりますがw
あのコントロール、Windows 標準ではないはずですが、秀〇エディタさんも E〇Editor さんも同じ外観で実装されてるのが不思議です。あの仕組みさえ分かればなんとかなるかもしれないのですが。
…で、調べていたらようやく分かりまして、どうやら、通常のテキスト ボックスの下に、同じ幅のコンボ ボックスが隠れているだけのようでした😅
[▼] ボタンを押すと、まるでテキスト ボックスの下からにょい～んと、ドロップダウンが表示されるかのように見える仕掛けのようです。(たぶん)
なんだか、実装できそうな気がしてきました。
というわけで、検討結果を以下にまとめておきます。
・[検索する文字列] の文字数上限を 8000、改行の数上限を 100 にします。
→ これらの上限を超える場合、[検索する文字列] は空になります。・[検索する文字列] に入力できる文字数の上限を 30000 にします。
→ これは、Windows 標準のコンボ ボックスのデフォルト上限値が 30000 であるためです。(Delphi では勝手に上限値が 0 [指定なし] になるようです)
→ 手動で入力する場合、30000 文字まで入力でき、重くなりますが、ユーザーに任せることにしました。・可能であれば複数行入力をサポートします。
→ ただし、混乱を招く可能性があるため、複数行入力モードへの自動切り替えは行いません。
→ 複数行入力モードでも、上記の文字数制限 (8000 文字 と 改行 100 個) を適用します。| Kuro | 返信 -
> 通常、改行を含む検索文字列は最大でも 1、2 個程度かと思われます。1000 個の改行を含む検索文字列となると誤操作の可能性が高いでしょうね。
そうですよね、数十行もの完全一致を検索するなんてなかなかやるケースが思い浮かびませんし、なんなら100行でもかなり余裕を持っている感じはありますね。
> …で、調べていたらようやく分かりまして、どうやら、通常のテキスト ボックスの下に、同じ幅のコンボ ボックスが隠れているだけのようでした😅
おお、芸術点の高い方法で成り立っていたのですね、アレはｗ
> ・[検索する文字列] の文字数上限を 8000、改行の数上限を 100 にします。
> → これらの上限を超える場合、[検索する文字列] は空になります。いいと思います。
> ・[検索する文字列] に入力できる文字数の上限を 30000 にします。
> → これは、Windows 標準のコンボ ボックスのデフォルト上限値が 30000 であるためです。(Delphi では勝手に上限値が 0 [指定なし] になるようです)
> → 手動で入力する場合、30000 文字まで入力でき、重くなりますが、ユーザーに任せることにしました。いいと思います。
そんなに長い検索するときはコピペしてねということで。> ・可能であれば複数行入力をサポートします。
> → ただし、混乱を招く可能性があるため、複数行入力モードへの自動切り替えは行いません。
> → 複数行入力モードでも、上記の文字数制限 (8000 文字 と 改行 100 個) を適用します。おおー！実装できそうな糸口が見えたということで、ありがとうございます。
自動切り替えはしない、というのは、秀丸っぽくコンボボックス横のメニューでON/OFFするということでしょうか？
それでもいいとは思うのですが、秀丸の検索で改行付き文字列をペーストしたときの自動で複数行テキストボックスに自動切り替えされるのはMeryでも相性良さそうな印象を受けたのですが、いかがでしょうか？以下のような立て付けで自動切り替えができると、混乱を抑えつつ利便性が上がるのでは、と思いました。
## 改行付き検索をしようとしていることが確実なケース
・改行付き文字列を検索文字列にペーストした場合
・検索文字列に Ctrl+Enter で改行を入力した場合→改行を明確に扱おうとしているので、複数行入力モードに自動切り替えしてもいい気がします
## 改行付き文字列を検索しようと思っているか不明なケース
・複数行の範囲選択をしてから検索ウィンドウを表示した場合
→改行付き検索だけでなく範囲のみ検索/置換をしたいだけの可能性はあるので、現行と同様にゼロ幅文字で表示する
| yuko | 返信 -
> →改行付き検索だけでなく範囲のみ検索/置換をしたいだけの可能性はあるので、現行と同様にゼロ幅文字で表示する
ちょっと曖昧な表現だったので一応訂正を…
訂正: →改行付き検索だけでなく範囲のみ検索/置換をしたいだけの可能性はあるので、現行と同様に通常のコンボボックスで改行はゼロ幅文字で表示する
| yuko | 返信 -
仕様のご確認、ありがとうございます。
> 自動切り替えはしない、というのは、秀丸っぽくコンボボックス横のメニューでON/OFFするということでしょうか？
はい、そのとおりです。
通常の用途では、複数行入力はほとんど必要ないことから、必要なユーザーだけが自分でオン/オフできる仕様を考えています。
自動切り替えでは、ユーザーが切り替える方法を把握できず、元に戻す方法がわからなくなる可能性がありますからね。
> ・改行付き文字列を検索文字列にペーストした場合
この場合、秀〇エディタさんでは自動で複数行入力になりますが、これは上記の理由から、ユーザーが混乱することが予想されます。
また、行単位でコピペするケースは割とよくあるので、1 行目のみが貼り付けられる現行の仕様のほうが逆に便利かもしれません。
> ・検索文字列に Ctrl+Enter で改行を入力した場合
Ctrl + Enter はあまり知られていない機能なので、自動で切り替えても問題ないかもしれませんね。
また、初心者さんが誤って Ctrl + Enter を押してしまうリスクを回避するなら、Ctrl + Enter の機能を廃止して、複数行入力は完全に手動で切り替える、というのも考えられます。
ちなみに、秀〇エディタさんは Ctrl + Enter は動作しませんでした。
ところで、秀〇エディタさんは複数行入力の場合、Enter キーで改行を入力できますが、これにより Enter キーで [検索] が実行できなくなってしまうんですよね。
かといって、E〇Editor さんのように、複数行入力の場合でも Ctrl + Enter を使わなければならないのは少し面倒ですし。
このあたりの仕様は検討の余地がありそうです。
> ・複数行の範囲選択をしてから検索ウィンドウを表示した場合
> →改行付き検索だけでなく範囲のみ検索/置換をしたいだけの可能性はあるので、現行と同様に通常のコンボボックスで改行はゼロ幅文字で表示するこの点に関しては同意です。秀〇エディタさんも、この場合は自動切り替えは行わないようですね。また、E〇Editor さんの場合、完全に手動で切り替える仕様でした。
> おお、芸術点の高い方法で成り立っていたのですね、アレはｗ
あはは、あれは笑いました。最初はコンボ ボックスに複数行入力できる隠し機能があるのかと、Windows API のメッセージ (ES_MULTILINE とか) をいろいろと試してみたんですよ😄
結局、Delphi のコンポーネントを購入しようかとまで考えましたが…🤣
でも、まだあのアクロバティックな UI を作っているところで、しばらくは時間がかかりそうです。
| Kuro | 返信 -
> 自動切り替えでは、ユーザーが切り替える方法を把握できず、元に戻す方法がわからなくなる可能性がありますからね。
>
> > ・改行付き文字列を検索文字列にペーストした場合
>
> この場合、秀〇エディタさんでは自動で複数行入力になりますが、これは上記の理由から、ユーザーが混乱することが予想されます。なるほど、元に戻す方法が分からなくなるのが混乱の元、ということでしたか。
秀丸で改行付き文字列を貼り付けたときに コンボボックス → 複数行入力テキストボックス への自動切り替えは「一時的」という扱いで (すでにご存知かとは思いますが、一応下記にキャプチャ)、検索ウィンドウをそのまま閉じてもう一度開けばいつものコンボボックスになっているので、この一時設定扱いな仕様を踏襲すればあまり「いつの間にか複数行入力テキストボックスになってしまって、戻し方が分からない」という混乱は招かないのではないかな、とふんわり考えていました。
https://imgur.com/a/7IidgGK
…が、検索ウィンドウを開きっぱなしで使うタイプのユーザーさんの場合、同じ検索ウィンドウを使いまわしますから、コンボボックスに改行付き文字列を貼り付けて意図せず複数行入力テキストボックスに切り替わってしまったりしたら「どこから戻すんだ？」ってなることはあるかもしれませんね。> また、行単位でコピペするケースは割とよくあるので、1 行目のみが貼り付けられる現行の仕様のほうが逆に便利かもしれません。
おや、、、私がMeryの仕様を読み違えていたようです。
複数行選択からの検索、とするだけで検索文字列が行をまたげるようになった今、「a\nb」という文字列を検索文字列にコピペしたら「a<ゼロ幅文字>b」というテキストで貼り付けられるとばかり思っていました。ここは1行目だけ貼り付けだったんですね。この仕様を変えてほしいとかそういった希望は特にありませんが、もしも改行付き貼り付けに対応するとしたら、行番号クリックして1行選択してコピーし検索文字列に貼り付けをしたときのように「貼り付け文字列末尾が改行」な場合には以下理由から、末尾改行を消すような正規化を入れた方が扱いやすそうです。
- 理由1: 検索文字列の末尾に改行があると、内容一緒で末尾がEOFな行がヒットしない
- 理由2: 改行含む1行での検索で、改行を含んで検索する意識はなかったのに コンボボックス → 複数行入力テキストボックス に勝手に切り替わるのはちょっと煩わしい今思ったのですが、理由1については現状も引っかかる場面があるかもしれませんね。
現状、以下のような文字列で、1行目「abc」を行番号クリックで選択 → 検索ウィンドウ表示して検索 …とすると改行込みでの検索なので1行目しかヒットしませんが、改行は検索ウィンドウ上はゼロ幅文字となっていることもあり、ヒットしない原因が分かりづらいかもしれません。さらに改行やEOFといった区別が付いてないユーザーの場合には余計に混乱するかも、、、と。abc<改行> def<改行> abc<EOF>現状の「範囲選択からの検索ウィンドウ表示」操作時の検索文字列はEOF対策のために、選択範囲末尾が改行だった場合には末尾改行を削除するようにしたほうがよさそうな気がしました。
> Ctrl + Enter はあまり知られていない機能なので、自動で切り替えても問題ないかもしれませんね。
VSCodeの場合には、検索文字列内での改行は単行でも複数行になってからも Ctrl+Enter でやるみたいですね。そして検索実行はいつも通りEnterで、という感じ。
そんな仕様を眺めて、仮に Ctrl+Enter で複数行入力テキストボックスに切り替わるとしたら、改行は切り替わったあとも Ctrl+Enter の方が分かりやすいなと思いました。
「Ctrl+Enter (改行しつつ複数行入力テキストボックスに切り替わり) → 切り替わってからは複数行入力テキストボックス内では改行がEnter、検索が Ctrl+Enter に変化」というのは改行と検索のキーが入れ替わるのがなんだかちょっと忙しい感じがします。Ctrl+Enter は知る人ぞ知る改行の裏技、という前提だとすれば、以下のような仕様もアリかもしれません。
前提: 「複数行入力」はコンボボックスの横のメニューから ON/OFF を設定できる
「複数行入力」OFF の場合の動作:
- 検索ウィンドウ表示時の初期状態はコンボボックス
- Ctrl+Enter での改行入力に合わせコンボボックスから複数行入力テキストボックスに自動切り替え
- Ctrl+Enter での複数行入力テキストボックスへの自動切り替え以外は、切り替え契機なし (前述の改行付き文字列貼り付けでの切り替わりはしない)
- 改行入力はコンボボックス、複数行入力テキストボックス問わず Ctrl+Enter
- 検索はコンボボックス、複数行入力テキストボックス問わず Enter「複数行入力」ON の場合の動作:
- 検索ウィンドウ表示時の初期状態は複数行入力テキストボックス
- 改行入力は Enter
- 検索は Ctrl+Enter
※「複数行入力」ON を使うのはコンボボックスの状態に戻る契機が無くてもいい、検索文字列をいつもテキストボックス的に操作したいユーザーだと思うので、従来の Enter/Ctrl+Enter は逆転させてもいい気がする。> でも、まだあのアクロバティックな UI を作っているところで、しばらくは時間がかかりそうです。
また貴重な休日のお時間とらせるようなことを言ってしまって、すみません、、、😅
ただ前回コメントさせていただいたように、私としては文字数・改行数の制限で動作速度の影響が緩和されれば個人的には十分だとは思っているので、複数行入力テキストボックスの実装や自動切り替えの仕組みをどこまで盛り込むのかは最終的にKuroさんの肌感 (と乗り気) にお任せします。なにか参考になることもあるかもしれませんので感想程度に意見だけは書きますが、軽く聞き流していただいても構いませんので。| yuko | 返信 -
ご提案いただきありがとうございます。
> 複数行入力テキストボックス への自動切り替えは「一時的」という扱いで (すでにご存知かとは思いますが、一応下記にキャプチャ)
スクショ、ありがとうございます。
私の秀〇エディタさんは、常に複数行入力になってるなーと思っていたら、[一時的] というモードがあって、自動切り替えのときだけ、そのモードになるんですね。
この仕様は、ちょっと分かりづらいような気が…。スクショを見てようやく把握しました😅
> 現状の「範囲選択からの検索ウィンドウ表示」操作時の検索文字列はEOF対策のために、選択範囲末尾が改行だった場合には末尾改行を削除するようにしたほうがよさそうな気がしました。
なるほど、それは合理的ですね。選択範囲の末尾が改行文字だった場合、その改行文字を削除するようにしてみます。
> VSCodeの場合には、検索文字列内での改行は単行でも複数行になってからも Ctrl+Enter でやるみたいですね。
VSCode も複数行入力ができるんですね。入力ボックスの切り替えは発生しないようですが、常に Ctrl + Enter なんですね。
> また貴重な休日のお時間とらせるようなことを言ってしまって、すみません、、、😅
いえいえ。気になり始めると、つい時間を忘れて開発作業に没頭してしまうもので…😭
> なにか参考になることもあるかもしれませんので感想程度に意見だけは書きますが、軽く聞き流していただいても構いませんので。
お気遣いいただき、ありがとうございます。いただいたアイデアからいくつか採用させていただきたいと思います。
> 前提: 「複数行入力」はコンボボックスの横のメニューから ON/OFF を設定できる
はい、そのとおりです。
> 「複数行入力」OFF の場合の動作:
> - 検索ウィンドウ表示時の初期状態はコンボボックスはい。この場合、初期状態はコンボ ボックスとなります。
> - Ctrl+Enter での改行入力に合わせコンボボックスから複数行入力テキストボックスに自動切り替え
やはり、単行コンボ ボックスにおける Ctrl + Enter は廃止しようと思います。自動切り替えも行いません。(理由は後述します)
> - Ctrl+Enter での複数行入力テキストボックスへの自動切り替え以外は、切り替え契機なし (前述の改行付き文字列貼り付けでの切り替わりはしない)
Ctrl + Enter による自動切り替え、および、改行を含む文字列を貼り付けた場合の自動切り替えは行いません。完全に手動で切り替えていただくかたちになります。
> - 改行入力はコンボボックス、複数行入力テキストボックス問わず Ctrl+Enter
そうですね。これは採用させていただきまして、複数行テキスト ボックスでの改行入力は Ctrl + Enter とします。
> - 検索はコンボボックス、複数行入力テキストボックス問わず Enter
はい、これも採用させていただきまして、検索は常に Enter とします。
> 「複数行入力」ON の場合の動作:
> - 検索ウィンドウ表示時の初期状態は複数行入力テキストボックスはい。この場合、初期状態はテキスト ボックスとなります。
> - 改行入力は Enter
複数行テキスト ボックスでの改行入力は常に Ctrl + Enter とします。
> - 検索は Ctrl+Enter
単行/複数行にかかわらず、検索は常に Enter とします。
> ※「複数行入力」ON を使うのはコンボボックスの状態に戻る契機が無くてもいい、検索文字列をいつもテキストボックス的に操作したいユーザーだと思うので、従来の Enter/Ctrl+Enter は逆転させてもいい気がする。
yuko さんが最初におっしゃられていましたが、「改行と検索のキーが入れ替わるのがなんだかちょっと忙しい感じがします。」というのは、ここにも当てはまるような気がします。
改行と検索のキーを固定するメリットについて、実際に複数行入力を使ってみて思ったのは、改行入力が Ctrl + Enter、検索が Enter で固定されているなら、常に複数行入力 ON の状態でもまったく問題ないということです。
今まで単行入力でできていたことは、複数行入力でも同じ操作でできるわけですし、入力欄も大きくなって見やすくなりますし、単行入力に戻る理由は見当たりません。
強いて言えば、検索ダイアログの高さを節約したい場合ぐらいでしょうか😅
というわけで、常に複数行入力 ON で使うユーザーこそ、従来どおりの操作性のほうが良いのではないかと考えました。
そうなってくると、単行入力での Ctrl + Enter は心眼でしか見えないわけですし、それを標準的な操作とするよりは、いっそのこと廃止して、代わりに複数行モードの使用をお勧めする方が簡単で分かりやすいかなと思いました。
長くなってしまいましたが、一度この仕様で開発し、実際に使用してみて評価していただくのが良いかなと思っています。
文章だけでは伝えきれない部分もあるかと思いますので😁
| Kuro | 返信 -
気づけば大変に長文になってしまっていましたが、吟味していただいてありがとうございます。
> この仕様は、ちょっと分かりづらいような気が…。スクショを見てようやく把握しました😅
そうですねぇ、実際、自動で複数行に切り替わったあとのメニューで「複数行の状態を覚える」ってどういうことなの…ってなりました。
> なるほど、それは合理的ですね。選択範囲の末尾が改行文字だった場合、その改行文字を削除するようにしてみます。
ありがとうございます。よろしくお願いします。
> 改行と検索のキーを固定するメリットについて、実際に複数行入力を使ってみて思ったのは、改行入力が Ctrl + Enter、検索が Enter で固定されているなら、常に複数行入力 ON の状態でもまったく問題ないということです。
>
> 今まで単行入力でできていたことは、複数行入力でも同じ操作でできるわけですし、入力欄も大きくなって見やすくなりますし、単行入力に戻る理由は見当たりません。なるほど、複数行入力モードの立ち位置を現在の改行仕様を表示上わかりやすくしたものにする、みたいな感じですか。それもいいですね！
検索条件には単行しか使わない派 (あるいは行またぎは正規表現派) には従来のコンボボックスを、ということですね。> 強いて言えば、検索ダイアログの高さを節約したい場合ぐらいでしょうか😅
従来のコンボボックスが改行機能のない簡易表示版みたいになるので、そうですね。
複数行のときに何行の表示にするかは結構悩ましそうですね。コンパクトさを重視して2行か、はたまた表示量を増やすために3行か…あるいは可変幅という選択肢も…!? (いや、さすがに標準部品では難しそうですね)> そうなってくると、単行入力での Ctrl + Enter は心眼でしか見えないわけですし、それを標準的な操作とするよりは、いっそのこと廃止して、代わりに複数行モードの使用をお勧めする方が簡単で分かりやすいかなと思いました。
心眼でしか見えないは、そのとおりですねｗ
単行入力で Ctrl+Enter したときの動作をただ廃止するよりも、改行しつつ複数行入力に "一時的に" 自動切り替え (検索ウィンドウを閉じて再度開けば単行入力にもどる) という扱いにしても、常に改行操作を使わない人には操作上の影響はなく、たま～に使いたい人はそのまま改行もできるというところで不都合はないのではと個人的には思いました。(食い下がるつもりはないので特に否はないのですが)
> 長くなってしまいましたが、一度この仕様で開発し、実際に使用してみて評価していただくのが良いかなと思っています。
>
> 文章だけでは伝えきれない部分もあるかと思いますので😁はい、色々とありがとうございました。仕様を練る過程、個人的に大変勉強になるなぁと拝見していました。
新しい仕様がどんなふうになるのか、楽しみにお待ちしております😎| yuko | 返信 -
Ver 3.6.3 リリースお疲れさまです🥳
> 検索/置換ダイアログで複数行の入力に対応
こちら、今のところ違和感なく使えています。ありがとうございます🙇♂️ 仕様検討から実装まで、大変お疲れさまでした。
とりあえずは2行くらい表示される感じで運用してみようと思っています。
…そして、さっそく気づいたことがあるので一応、ご報告です。とはいっても、Windows 11の標準コントロール部品の問題で、Mery云々ではないと思うのですが。
https://imgur.com/a/KraBCRH
- 上記1枚目: 2,3行程度の低い高さのテキストボックスだと、スクロールが必要になるくらいの改行を入れても、スクロールバーが表示されないようです。
- 上記2枚め: 4行以上程度くらいから、ちゃんとスクロールバーが表示されるようになります。ところで、複数行入力のテキストボックスの横スクロールを「水平スクロールバーを自動的に表示」の設定のように、横スクロールが不要な文字数の場合には水平スクロールバーを表示しないといったことは、標準のテキストボックス部品であることから察するに難しいですよね？
それができると検索ウィンドウの高さを節約できるのと同時に、「横スクロールがあるほどの文字列長なんだな」というのが認識しやすいので嬉しいのですが、難しいようならご放念ください。> [検索する文字列] に入力できる文字数の上限を 30,000 文字に制限した
> 選択範囲を [検索する文字列] に渡すときの文字数の上限を 8,000 文字、改行の数を 100 個に制限した
> 選択範囲を [検索する文字列] に渡すときに末尾の改行文字を削除するようにしたこのあたりのご対応もありがとうございました。これで不意に重たい検索をせずに済みそうです。
> VSCode に準拠しようと思いましたが、横スクロールを抑えられるという利点から、従来どおり、列のみカーソル位置を保持することにしました。
なるほど、横スクロール。言われてみれば横スクロールが頻発しない方が目に優しいですね。さすがの目の付け所です。
> [バージョン情報] ダイアログに [情報のコピー] ボタンを追加
こっそり嬉しい機能まで実装していただいてありがとうございます。報告する際に活用させていただきます。
| yuko | 返信 -
早速お試しいただき、ありがとうございます。
こちらこそ、仕様検討へのご協力、ありがとうございました🙇♂️
> …そして、さっそく気づいたことがあるので一応、ご報告です。とはいっても、Windows 11の標準コントロール部品の問題で、Mery云々ではないと思うのですが。
そうなんですよね。これは Windows 11 のスクロール バーの仕様で、マウス ポインターが乗っていないときはスクロール バーの上下ボタンが非表示になります。
マウス ポインターを乗せると、上下ボタンが表示されると思います。
ちなみに、Windows 11 の [設定] > [アクセシビリティ] > [視覚効果] > [スクロール バーを常に表示する] をオンにしても、デスクトップ アプリ (Mery のような Win32 アプリ) には効果がありません。
> - 上記2枚め: 4行以上程度くらいから、ちゃんとスクロールバーが表示されるようになります。
そうですね。最小サイズの制限を 4 行ぐらいに大きくすることはできますが、そうしてしまうと検索ダイアログを小さくしたいときに不便ですからね。
> ところで、複数行入力のテキストボックスの横スクロールを「水平スクロールバーを自動的に表示」の設定のように、横スクロールが不要な文字数の場合には水平スクロールバーを表示しないといったことは、標準のテキストボックス部品であることから察するに難しいですよね？
はい。Windows 標準のテキスト ボックスには、スクロール バーを [表示しない]、[横のみ表示]、[縦のみ表示]、[両方表示] しか用意されておらず、横スクロールを自動的にオン/オフはできないですね。
そこに Mery のエディターコンポーネントを埋め込むのも重すぎると思いますし。
> > VSCode に準拠しようと思いましたが、横スクロールを抑えられるという利点から、従来どおり、列のみカーソル位置を保持することにしました。
> なるほど、横スクロール。言われてみれば横スクロールが頻発しない方が目に優しいですね。さすがの目の付け所です。当初はバグかと思った仕様でしたが、メモ帳、ワードパッド、Visual Studio、Word などを使っていて、その仕様の意図に気付いたときは、Microsoft さん、やりますな。と思いました😁
> こっそり嬉しい機能まで実装していただいてありがとうございます。報告する際に活用させていただきます。
どういった情報が必要なのか…という懸念事項はありましたが、とりあえず実装しておいて、後から必要に応じて項目を追加/削除すれば問題ないかということで、対応してみました。
| Kuro | 返信 -
> そこに Mery のエディターコンポーネントを埋め込むのも重すぎると思いますし。
ですねぇ、そこまで全力で編集機能を求めたい部分でもないですし…。標準テキストボックスで十分かと思います。
> はい。Windows 標準のテキスト ボックスには、スクロール バーを [表示しない]、[横のみ表示]、[縦のみ表示]、[両方表示] しか用意されておらず、横スクロールを自動的にオン/オフはできないですね。
自動オン/オフはできないものの、縦だけとか横だけとか、バリエーションがあるんですね。
個人的には検索ウィンドウでスクロールバーをマウス操作で動かすってことがなさそうなので (元々コンボボックスのときもスクロールバーはないのが当たり前でしたし)、表示領域を確保できる [表示しない] は案外良さそう、とちょっと思いました。
スクロールバーを表示する or 表示しない も、 [複数行] のオン/オフ設定の下あたりに用意してみるのもいいかもしれません。| yuko | 返信 -
> スクロールバーを表示する or 表示しない も、 [複数行] のオン/オフ設定の下あたりに用意してみるのもいいかもしれません。
そうですね。テキストが長い場合、横スクロールがないと不便かもしれませんが😅
…と思って秀〇エディタさんを確認してみたら、[複数行] の下に、[右端で折り返す] というオプションがありました。これなら横スクロールの必要もないので、アリかもしれませんね。
ただし、項目を増やすと、[正規表現を使用する] をオンにしたときの、ポップアップ メニューがかなり長くなりますね。
| Kuro | 返信 -
> ただし、項目を増やすと、[正規表現を使用する] をオンにしたときの、ポップアップ メニューがかなり長くなりますね。
なるほど、正規表現オンのときの入力テンプレートも兼ねていたのですね。
メニューバーの
[編集] > [選択範囲の変換] > *****
などのようなイメージで、多段メニューにでもできると高さを節約できそうですが、いかがでしょう？| yuko | 返信 -
そうなんですよね。でも、多段メニューにすると、メニューをよく使うユーザーさんに怒られそうです😱
ちなみに、E〇Editor さんを見てみたら、結構な長さ！正規表現のテンプレートはやっぱり長くなりがちなんですね。画面からはみ出しそうな感じです。
それに比べて、Mery のメニューはまだましでした。
余談ですが、エディターのアップデートが相次いでいるようで、11月16日に秀〇エディタさんが Ver 9.2.5 を、E〇Editor さんが Ver 23.0 をリリースしているんですよね。
しかも、リリース直後にバグが見つかる現象なのか、どちらも翌17日に Ver 9.2.6 と、Ver 23.0.1 がリリースされていて、「やっぱりそうだよね！」と思いました🤣
しかし、秀〇エディタさんの新機能、ITA モード (痛モード？) は面白いです。
GPU のパワーを使ってエディターウィンドウを透過したり、背景画像を描画したりできるみたいです。そのうち、初音ミクを踊らせたりなんかできるようになったりして。
あ、ところで、[右端で折り返す] って、あったほうがいいでしょうか？😅
| Kuro | 返信 -
> そうなんですよね。でも、多段メニューにすると、メニューをよく使うユーザーさんに怒られそうです😱
まぁ、よほど耐えきれなくなったときの最終手段でしょうかね。 (EmEditorよりは短いのでまだまだいける！ということで)
> しかし、秀〇エディタさんの新機能、ITA モード (痛モード？) は面白いです。
ターミナルとかも透過してるだけでちょっと格好良く見えるフシがあるので (気のせい？)、いいかもしれませんね。格好良さと引き換えに見づらくはなっちゃいますがｗ
> あ、ところで、[右端で折り返す] って、あったほうがいいでしょうか？😅
そうですね、お手間でなければ、使ってみたいです。
右側で折り返して縦スクロールバーはあり、横スクロールバーはなし、って感じの仕様でしょうか。
私の場合、縦は2行表示 (スクロールバー含むと3行分程度の高さ) されるように使っているので、横スクロールバーが無くなるだけでテキストボックス縦幅が 1/3 の削減ができてよさそうです。ちなみにウィンドウ横幅は最小幅まで狭めて使っているのですが、折返しなら2行分で全角50文字程度は表示できそうなので、私の利用上ではほとんどのケースでスクロールせずにすべての検索文字列が収まりそうで、なかなか良さげだなぁと想像しています。
| yuko | 返信 -
> ターミナルとかも透過してるだけでちょっと格好良く見えるフシがあるので (気のせい？)、いいかもしれませんね。格好良さと引き換えに見づらくはなっちゃいますがｗ
格好よく見えますよねー。見づらさに加えて、私の GPU だとちょっとカクカクでしたがw 新しい機能はついどうやって実装するのか試してみたくなるものですね。ここは我慢、我慢…。
> > あ、ところで、[右端で折り返す] って、あったほうがいいでしょうか？😅
> そうですね、お手間でなければ、使ってみたいです。わかりました。Windows 標準の機能でできる範囲なので、それほど手間はかからないと思います。
> 右側で折り返して縦スクロールバーはあり、横スクロールバーはなし、って感じの仕様でしょうか。
そうなりますね。
> ちなみにウィンドウ横幅は最小幅まで狭めて使っているのですが、折返しなら2行分で全角50文字程度は表示できそうなので、私の利用上ではほとんどのケースでスクロールせずにすべての検索文字列が収まりそうで、なかなか良さげだなぁと想像しています。
おっしゃるとおり、長いテキストってそんなに頻繁に検索するものでもないですし、常に横スクロールバーが表示されているより、右端で折り返しのほうが合理的かもしれませんね。
次のバージョンで実装する方向で検討してみます。
| Kuro | 返信 -
> 格好よく見えますよねー。見づらさに加えて、私の GPU だとちょっとカクカクでしたがw 新しい機能はついどうやって実装するのか試してみたくなるものですね。ここは我慢、我慢…。
今どきだと5万円くらいで統合GPU機能の強いRyzen機なんかも手に入るものの、普段の作業で事足りてるところに買い足すにはそれでも痛い値段ですしねー、、、
> 次のバージョンで実装する方向で検討してみます。
ありがとうございます。いつものことながら、次のバージョンも楽しみです😊
| yuko | 返信
