Greg Pomerantz 6bd5588ade editor: don't clamp the restored scroll offset against an unmeasured MaxScroll ... maybeApplyRestoreScroll applied the offset as soon as the content had landed, then clamped it to MaxScroll. For a string buffer (small file) MaxScroll derives from the shaper's last baseline, which is still 0 at that point - nothing has shaped yet - so every restored offset was clamped to 0 and the scroll position was silently lost on relaunch (the line-pin that re-derives the offset had already been armed from the zeroed value). Wait for the first shaped frame (its feedback triggers the emitFrame that re-runs the apply; a chunked buffer's MaxScroll is measured from the line index and needs no such wait). A deadline bounds the wait so content that never produces a baseline (empty, newlines-only) cannot leave the restore armed forever - it lands best-effort. Verified on the emulator: 120-line file, scroll to line 75, relaunch - lands at line 75 (log: RESTORE scroll off=1272.7 line=75 maxScroll=1272.7; before the fix: off=0.0 maxScroll=0.0).		2026-09-20 10:48:52 -04:00
..
browser	Reload the previous directory's list after a failed navigation	2026-09-03 12:53:23 -04:00
editor	editor: don't clamp the restored scroll offset against an unmeasured MaxScroll	2026-09-20 10:48:52 -04:00
io/pool	IME: map commits against the whole buffer; drop the renderer-side model	2026-09-13 11:57:38 -04:00
perf	Add pre-release frame-regression profiling	2026-08-20 14:18:08 -04:00
test/e2e	IME: accept the one stale-caret commit after a key-event edit; fix the IME hold	2026-09-19 21:52:35 -04:00
ui	editor: don't record a phantom trailing visual line at the window end	2026-09-20 07:49:52 -04:00