[BUG] Wrapped lines Vim `j` and `k` idiosyncracies

[corpserot]

ZenNotes feature/zennotes-cloud branch (3933732). basically, current HEAD of that branch as of writing this.

I verified that the previous two bugs I reported no longer occur, thanks! I wouldn't say that those fixes introduces new bugs, but more likely that wrapped lines were just not given enough free form testing. i did not use any zoom out/in for these recordings.

With logical lines going up and down behaves as so.

jk.logical.lines.correct.mp4

With wrapped lines, it behaves in a quirky unexpected way as shown in the videos below.

jk.sticky.bug.mp4

jk.sticky.bug.2.mp4

[adibhanna]

Fixed on the branch in 4c077f3, and thank you for testing the previous fixes and filing this with videos again. You were right that this was not introduced by them: it was a third, pre-existing quirk that only became visible once the first two stopped hiding it.

What was happening. Your frames show the cursor coming to rest exactly ON a soft-wrap point, the offset that is both "end of row N" and "start of row N+1" (the thin bar past the last character of the row). On your display the coordinate query resolves a right-edge goal column to that offset, and the vim adapter then reads it as belonging to the NEXT row while drawing the cursor at the end of the previous one. From that state, one j skipped a row and one k bounced back to the start of the row you were already on, which is the quirky wandering in your recordings.

The fix. A landing on a wrap point is now disambiguated by the goal column j/k carry. When the goal sits at the right edge, the cursor rests on the row's last character (the same spot $ chooses), so the ambiguous state can no longer arise while navigating; with a left-side goal the landing keeps the next row's start, so ordinary column-0 scanning is unchanged.

Verified in the running app by reproducing your machine's coordinate resolution at the exact seam it differs: before the fix the cursor rested on the wrap point and the next j skipped a row; after it, every press moves exactly one visual row, in both directions, at any goal column we could throw at it.

Ships in the next release with the rest of the wrapped-line fixes. If any wrapped-line movement still looks off on your build after pulling this, the same kind of video gets it fixed fastest.

[corpserot]

hmm i think you missed the mark this one. i apologize if i had not made it clear enough. It seems to me that zennotes has no idea what to do when the cursor is trying to jump off the longer display line. as shown in the first video, the behaviour for logical lines is to not skip the shorter lines when the cursor sits on the far side of the longer line. instead it is "sticky" to the end of the logical line remembering the goal column. thusly, a similar behaviour is expected for display lines. this behaviour is also one that WYSIWG programs do such as in MS Word.

the video is recorded with the current HEAD of the feature branch, which is 6aa9239 as of writing this.

jk.sticky.bug.3.mp4

as remarked in #575 (comment) i do not have permission to reopen issues, and i should not open a new one in this case either as the problem persists.