[BUG] Vim `j` and `k` inserts the actual character on a line long enough to wrap into 5+ display lines

[corpserot]

ZenNotes v2.27.0

it's strange, video best shows what is happening. it happens when the text is very long. i was trying to show a different bug but found this instead. it happens when the long text is wrapped into 5 display lines or more.

move.down.bug.mp4

move.up.bug.mp4

EDIT: it gets weirder, it only happens on certain zoom levels both zooming in and zooming out. the video was recorded with -1 zoom (meaning i zoomed out once)

[corpserot]

this one might be related too. i did not enter insert mode at all. you can ignore the last part about how $ doesn't travel to the actual line end, that's the bug that i wanted to report initially.

dollar.insert.bug.mp4

[adibhanna]

Thanks for the videos, they made this findable. Fixed on the current development branch, twice over:

What was happening. ZenNotes maps j/k to move by display line through soft-wrapped text, and that motion asks CodeMirror for pixel coordinates. On some geometries (your fractional display scaling at certain zoom levels, once the line wraps into enough rows) that coordinate query throws inside CodeMirror's view code. The vim layer rethrows motion exceptions after resetting itself, which skips the keydown's preventDefault, so the key you pressed falls straight through to the editor as text. That is why a bare j in normal mode typed a j into your note, with no insert mode involved. The zoom dependence and the 5-row threshold are just what it takes for the coordinate math to hit the crashing case on your setup.

The fix.

• 16b6f9c: every pixel-based vim motion (j/k, $, g0, H/L, and the display-row A/I) now catches a measurement failure and falls back to plain logical-line movement for that press. A crash in the coordinate code can never again type into the note; worst case a single press moves by logical line instead of display row.
• 5981980: updates @codemirror/view 6.41.0 to 6.43.8, which fixed several crashes in exactly this code upstream (tile tree corruption, inconsistent posAtCoords results), so the throw itself should be gone too.

Both land in the next release.

About $ in your follow-up video: bare $ stopping at the end of the visible row rather than the logical line end is deliberate (#536), mirroring how j/k move by display row; a counted $ still targets logical line ends. If that behavior gets in your way in practice, please open a separate issue and we can talk bindings.

I could not reproduce the crash on macOS at any zoom level or display scale, so the guard was verified by injecting the same class of failure into the running app and confirming j/k move instead of typing. If you can still trigger it after the next release ships, please reopen with your zoom level and display scale.