[自動でウィンドウ幅に合わせる]処理高速No.03813
inouen さん　04/01/17 22:39
　
inouenです。

エディタ的(改行だけを数える)の場合、ウィンドウサイズ変更時に折り返し計算を
再度行われていますが、少なくとも行のinsert/deleteが無かった場合不要と思われ
ます。

単純にウィンドウに表示されている最初の行から新しい幅で再表示するだけで可能だと
思われますので検討をお願いします。

また行のinsert/deleteがあった場合、行内容に追加があった場合も、全ソーススキ
ャンは
不要で、編集中に行われる　行番号-ソースメモリアドレス対応表(?)の変更で自動的に
対応出来ているように思われます。

現状では 数十MBオーダーのプログラム出力ログファイルをエディタ的で開いた場合、
初期表示が終わるまでに主に折り返し計算で数分以上かかり、このモードでは使用する
気持になれません。

現在ソース読み込み時に途中経過行数が表示され、これは数十秒オーダーで終わって、
その後折り返し計算が始まっています。
この読み込み時に対応表を同時に作るように出来ないものでしょうか。

各種言語、文字コード、フォント処理等をサポートされているために簡単に出来ない
こともあるかとは思いますが、高速化の方向で検討よろしくお願いします。
[ △ ]
RE:03813 [自動でウィンドウ幅に合わせる]No.03823
秀丸担当 さん　04/01/19 15:32
　

>現在ソース読み込み時に途中経過行数が表示され、これは数十秒オーダーで終わっ
>て、
>その後折り返し計算が始まっています。
>この読み込み時に対応表を同時に作るように出来ないものでしょうか。

たぶんこの状態になるのは、行番号の計算方法がエディタ的であるかどうかに関
わらず折り返し計算に時間がかかっていると思います。
行番号表示がONのとき、行数が増えると、行番号表示の桁数も増えて、折り返し
文字数も必然的に変わります。
すると、サイズ変更していないのに、サイズ変更したのと同じ処理を行わなけれ
ばならず、時間がかかってしまいます。

「ウィンドウ幅に合わせる」のときは行番号表示の桁数を最大の7桁に固定にし
てしまうと回避できると思います。
あるいは、ファイルを読み込む前にそのファイルの行数が推測できれば回避でき
ますが、推測は難しいです。
[ △ ]
RE:03823 [自動でウィンドウ幅に合わせる]No.03837
inouen さん　04/01/19 21:10
　
>行番号表示がONのとき、行数が増えると、行番号表示の桁数も増えて、折り返し
>文字数も必然的に変わります。
>すると、サイズ変更していないのに、サイズ変更したのと同じ処理を行わなけれ
>ばならず、時間がかかってしまいます。
>
>「ウィンドウ幅に合わせる」のときは行番号表示の桁数を最大の7桁に固定にし
>てしまうと回避できると思います。
>あるいは、ファイルを読み込む前にそのファイルの行数が推測できれば回避でき
>ますが、推測は難しいです。

現在の表示トップ行から20-50行程度を表示すればよいのでファイル全体で何行になり、
行番号表示に何桁用意するべきかは関係ないのではないでしょうか。
たとえば現在行番号＋１００で行番号桁数を決めればよいと思います。
[ △ ]
RE:03837 [自動でウィンドウ幅に合わせる]No.03839
アルビレオ さん　04/01/19 21:37
　
アルビレオです。

>現在の表示トップ行から20-50行程度を表示すればよいのでファイル全体で何行にな
>り、
>行番号表示に何桁用意するべきかは関係ないのではないでしょうか。
>たとえば現在行番号＋１００で行番号桁数を決めればよいと思います。

これって、けっこう大きな変更になりそうですが…
今の仕様だと桁数が変化するのは、ファイルの読み込み/文字の挿入や削除/置換
などですが、これに加えてスクロールやジャンプでも桁数の変化をチェックしな
ければいけません。

高速化の手段としては有効だと思いますが、カーソルキーの上下でスクロールし
ただけでウィンドウ全体を再描画するのがちょっと嫌かもしれません。
[ △ ]
RE:03839 [自動でウィンドウ幅に合わせる]No.03840
inouen さん　04/01/19 22:27
　
>アルビレオです。
>
>>現在の表示トップ行から20-50行程度を表示すればよいのでファイル全体で何行にな
>>り、
>>行番号表示に何桁用意するべきかは関係ないのではないでしょうか。
>>たとえば現在行番号＋１００で行番号桁数を決めればよいと思います。
>
>これって、けっこう大きな変更になりそうですが…
>今の仕様だと桁数が変化するのは、ファイルの読み込み/文字の挿入や削除/置換
>などですが、これに加えてスクロールやジャンプでも桁数の変化をチェックしな
>ければいけません。
>
>高速化の手段としては有効だと思いますが、カーソルキーの上下でスクロールし
>ただけでウィンドウ全体を再描画するのがちょっと嫌かもしれません。


たしかにスクロールなどについては考えていませんでした。

全体の行番号桁数を統一するのであれば、最初の読み込み時、行の挿入、削除の時、
全行数をチェックしておけばエディタタイプの場合十分だと思います。

気になっていたのは窓幅変更の時、全ソースファイルをスキャンしての折り返し
再計算は不要ということです。
全行数の桁数を共通に参照して行番号部分の出力桁数を決める処理は
いずれにしろ現状でも行われているはずと思います。

変更としては折り返し桁数の再スキャンを削除する、
行の挿入、削除時に最終行番号桁数をチェック、セットする
同桁数増大(減少)時の再表示
程度で大幅な変更にはならないのではと思います。
[ △ ]
RE:03840 [自動でウィンドウ幅に合わせる]No.03841
アルビレオ さん　04/01/19 23:12
　
アルビレオです。

>気になっていたのは窓幅変更の時、全ソースファイルをスキャンしての折り返し
>再計算は不要ということです。

それでも「ワープロ的」行番号表示のためには少なくとも表示位置より前にある
テキストは全てスキャンする必要があります。
最悪パターンとしては巨大ファイルを読み込んだ直後にファイル末尾へ移動する
ときですが、この場合でも理論上は今の仕様でウィンドウ幅を変えたときと同程
度になりますね。

スクロールによって行番号の桁数が変化するときは行数カウントの再計算は必要
ないので、桁数の変化する境界付近でのスクロールによってウィドウの幅がヒョ
コヒョコ変わる以外には実害はなさそうです。

実装上はスクロール/ジャンプが発生する状況のリストアップに見落としがない
か、という点が気になりますが。
（マウスでウィンドウ上端や下端付近をクリックしたときや、範囲選択したテキ
ストをマウスでドラッグする場合の自動スクロールとか）
[ △ ]
RE:03841 [自動でウィンドウ幅に合わせる]No.03858
秀丸担当 さん　04/01/20 15:34
　

>>気になっていたのは窓幅変更の時、全ソースファイルをスキャンしての折り返し
>>再計算は不要ということです。

秀丸の内部構造上、ファイルの全てをスキャンすることは、必要です。
秀丸は、常にワープロ的（折り返しを数える）な行の管理をしています。
エディタ的（改行だけを数える）にすると、通常のワープロ的な処理に加えてエ
ディタ的な処理が加わることになります。

現状で一番大きな問題は、単純に折り返し文字数が変更してファイルの全てをス
キャンする処理が非常に遅いことです。この点を改善できればいいと考えていま
すが、いろいろなことが絡んでいて、難しい点が多くあります。
[ △ ]
RE:03858 [自動でウィンドウ幅に合わせる]No.03883
inouen さん　04/01/21 23:32
　
折り返し処理速度善については今後の改善を期待しています。

折り返し関連で思いついた要望事項を以下に記しますので検討をお願いします。

１．折り返し無しモードの追加
論理行：改行単位でどんなに長くても１行に表示するモード
もちろん表示出来ない部分は切り捨て
折り返し文字数を最大値：2000文字とすることでそのように長い
行は無いとすれば同じ効果が得られます。
ただ折り返し無しとすれば折り返し行数チェック処理をする必要が
無くなりますのでより効果的です。

2.  行番号表示桁数指定
ユーザー指定可能とする。3-7桁
フリーソフトでユーザー指定可能なものも有るようです。
ファイルタイプ別の設定項目とする

3.  ファイルサイズからの概略行数推定
もし必要であれば次のような方法もあるのではと考えました。
数MB以下のファイルは直接サーチして求める。数MB以上の場合は
ユーザーに１行あたりの平均バイト数を指定してもらう。
（ファイルサイズ/1行平均バイト数 * 安全率）で行番号表示桁数を決める。
このような処理をしたい場合は　MBオーダーの数種類の形式のデータの
繰り返しのような場合だと考えられますのでこれで行けると思います。

4. 横スクロールバー指定をキー操作で指定可能に
現在、動作環境での指定となっていますがこれでは横スクロールの不要な
ものにも適用されてしまいます。

折り返し無しモード等を使ったとして、ログファイル等を見ていてメッセージが
長いなどで窓からはみ出した部分をすぐに見たい場合、キー操作で
横スクロールバーの有り/無しを制御したいわけです。
ツールバーに入れるのも良いかも知れません。

またファイルタイプ別の指定も有ったほうが良いのではと思います。

5. 横スクロールバーのプルアップメニューのここにスクロールの位置変更
一番下の使いやすい場所に置いた方が使い勝手が良いようです。

以上　よろしくお願いします。
[ △ ]
RE:03883 [自動でウィンドウ幅に合わせる]No.03891
秀丸担当 さん　04/01/22 14:32
　

>１．折り返し無しモードの追加
内部構造上、折り返し無しにするのは困難です。

>2.  行番号表示桁数指定
>ユーザー指定可能とする。3-7桁

行番号の桁数を指定可能にできれば、大きなファイルを読み込んだ後に自動折り
返し計算が不要になるので、非常に有用だと思います。

>3.  ファイルサイズからの概略行数推定

行番号の桁数を得るためだけに、一行あたり平均バイト数から行数を推測するの
はいまいちのような気がします。
単純に、ファイルサイズが大きければ行番号の桁数を７桁にしてしまうという処
置だけでもいいかも。

>4. 横スクロールバー指定をキー操作で指定可能に

これはまた別の話として、将来的なネタとして検討することにします。

>5. 横スクロールバーのプルアップメニューのここにスクロールの位置変更
>一番下の使いやすい場所に置いた方が使い勝手が良いようです。

これはWindowsが勝手に出してくれているものです。
通常は、メニューは下方向に出てくるので、一番近い位置に「ここにスクロー
ル」がありますが、最大化したときはマウスカーソルが下のほうにあるので、メ
ニューが上方向に出るようです。
[ △ ]
RE:03891 [自動でウィンドウ幅に合わせる]No.03948
秀丸担当 さん　04/01/29 18:33
　

V4.10β13で、折り返し文字数の再計算処理が非常に遅かった部分を、高速に
（というか普通の速度に）にしました。

行番号の幅が変わることによって再計算される問題は、現状のままです。
[ △ ]