Problem
Pressing Enter at the end of a wrapped multi-paragraph document causes the viewport to jump wildly instead of tracking the caret. The jump shrinks with each Enter and mostly stops once enough blank lines have been added.
Root cause: every edit calls check_cache_rev, which clears the entire text-layout cache. When the scroll container then calls ensure_visible to follow the caret, vline_of_rvline walks up from the caret line looking for cached layouts. With the cache empty, find_vline_of_line_backwards falls back to counting 1 visual line per line, undercounting every wrapped paragraph above the caret. The resulting caret rect is at the wrong y, and Scroll jumps to "fix" it. Because each Enter leaves the cache in a different partial state (different lines re-laid-out by compute_screen_lines), the wrong answer differs each time — hence the alternation. New blank lines don't wrap, so the undercount shrinks as they accumulate.
How to reproduce
Copy this report into the editor example, move the caret to the end of the text, and press enter multiple times. If you maximize the app, the problem won't manifest, because the whole document fits and no scrolling is needed.
Quick fix
In ensure_visible, eagerly materialize text layouts for lines 0..=caret_line before calling vline_of_rvline. That gives the vline walk real wrap counts instead of the 1-per-line fallback.
Problem
Pressing Enter at the end of a wrapped multi-paragraph document causes the viewport to jump wildly instead of tracking the caret. The jump shrinks with each Enter and mostly stops once enough blank lines have been added.
Root cause: every edit calls
check_cache_rev, which clears the entire text-layout cache. When the scroll container then callsensure_visibleto follow the caret,vline_of_rvlinewalks up from the caret line looking for cached layouts. With the cache empty,find_vline_of_line_backwardsfalls back to counting 1 visual line per line, undercounting every wrapped paragraph above the caret. The resulting caret rect is at the wrong y, and Scroll jumps to "fix" it. Because each Enter leaves the cache in a different partial state (different lines re-laid-out bycompute_screen_lines), the wrong answer differs each time — hence the alternation. New blank lines don't wrap, so the undercount shrinks as they accumulate.How to reproduce
Copy this report into the editor example, move the caret to the end of the text, and press enter multiple times. If you maximize the app, the problem won't manifest, because the whole document fits and no scrolling is needed.
Quick fix
In
ensure_visible, eagerly materialize text layouts for lines0..=caret_linebefore callingvline_of_rvline. That gives the vline walk real wrap counts instead of the 1-per-line fallback.