A simple, high performance text editor.
Greg Pomerantz
e761436908
The screen->line tap mapping only needs the sub-line scroll remainder (tapLocalY adds r, never the full scroll) because the visible glyph layout is window-relative and IMEWindowStartByte re-anchors it to the file. That holds for every scroll offset IF the window start line k=floor(s/lh) and the sub-line remainder r stay consistent. Property test (4000 random scroll/tap pairs, asserting against an independent drawn-geometry ground truth, not the tap code's own math) exposed a real bug: int(s/lh) in the Dp float32 domain rounds the quotient to nearest and can round UP across an integer boundary while the float64 mod still reflects the line below. In a sub-pixel-wide band of scroll offsets the window started one line too far while the draw shift lagged by one line - the whole rendered window (and every tapped line) shifted by one. Fix: one shared float64 floor decomposition (scrollDecompose) used by the window start (visibleByteRangePrecise/Estimate), the renderer's sub-line shift (visibleScrollOffset), the tap mapping (tapLocalY), and chunk prefetching. Also route the shaper's line height (previously ignored by visibleByteRangePrecise) through VisibleByteRange. On-device cross-check: at s=4246.9 (r=13.3) and s=4210.7 (r=10.7), taps on visually identified lines typed markers that landed on exactly those lines in the file on disk; profiler ScrollDP, screenshot, formula, and disk all agreed. Docs: scroll decomposition invariant in architecture.md §6.2, pipeline hop 2 in doc/README.md, Phase 10 in development_plan.md. |
||
|---|---|---|
| .qwen | ||
| cmd/pad | ||
| doc | ||
| internal | ||
| scripts | ||
| .DS_Store | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||