A simple, high performance text editor.
Greg Pomerantz
3bc3ed3530
The GlyphLayout is shaped from the visible window alone, so its ByteOffsets are relative to the window start (IMEWindowStartByte). But SetCursorFromPoint, HandleHome, HandleEnd and HandleVerticalCursorMove treated them as absolute file offsets. On a large file scrolled deep, the cursor was set to a window-relative offset (near the file start), so the next EditorLayout computed visibleCursorPos = CursorPosition - start as a small/negative value and the IME selection snapped to the window top (regardless of where the user tapped). Add glyphBase() and convert at the four cursor boundaries: subtract the base before searching the window-relative offsets, add it back before storing the absolute CursorPosition. For small files (window == whole file) the base is 0 and the change is a no-op. Add TestTapToPosition_WindowBaseOffset, a regression test that sets a non-zero IMEWindowStartByte and asserts the cursor lands at base + window byte (fails on the pre-fix window-relative assignment). Verified on-device: with a 6 MB file scrolled to ~line 1200, a tap now places the cursor on the tapped line (typed text lands ~16 lines below the window top), where before it always landed on the window top. |
||
|---|---|---|
| .qwen | ||
| cmd/pad | ||
| doc | ||
| internal | ||
| .DS_Store | ||
| .gitignore | ||
| go.mod | ||
| go.sum | ||