[calvin-archastro]

Stet reached ~50 GB after editing a very long line. This bounds every cache that grew without limit.

Fixes

1. Layout cache bounded by size (66dd5ea): saved line layouts were capped only by count (3000). A laid-out line costs ~200–400 B per character, so a 330 KB line is ~100 MB per copy, and every edit kept another one. The cache now also clears once the saved text passes 1 MB.
2. Evict huge lines between redraws (77f1c29, 6142c69): when typing outruns redraws, every key made a new copy and nothing was cleared until the next redraw. Copies of lines ≥16 KB are now dropped as each key is typed, keeping the 2 most recent. A line the current redraw is already using is never dropped.
3. Free image textures (ceba93f): GPU textures were never freed (each retouch save, closed doc and URL edit added one for good). Pictures not drawn for 60 s are freed, and textures are capped at 512 MB, but never anything drawn in the last 2 s. A picture that comes back reloads under a new id. Decoding is limited to 16384 px per side and 1 GiB of memory.

Measured (peak memory footprint, release build)

Repro	Before	After
200 keys at 0.02 s into a 330 KB line	53 GB	0.8–1.3 GB
12 × 4000² PNGs in 2 docs, 70 s after scrolling	1363 MB	502 MB

Not fixed

• During slow typing, memory creeps up a few MB per key and drops when idle. In-use memory stays flat at ~320 MB; the growth is memory macOS's allocator has freed but not yet returned.
• Freed pictures keep a small entry in the image cache, and a picture embedded in the text as a data: URI keeps its full text there.

Checks

• cargo fmt --check, cargo clippy --workspace (0 warnings), cargo test --workspace all pass. Unit tests cover the huge-line eviction and the texture eviction.
• Screenshots: README renders normally; evicted pictures reload when scrolled back to.

🤖 Generated with Claude Code