V1.0.1 Vim gj and gk still offsets after clicking with mouse

[rigmarole]

Steps to reproduce

In v1.0.1 some offset behaviour was fixed for Vim bindings gj and gk. However, there is still an issue.

1. With the cursor in a certain position, use the mouse to click somewhere else.
2. Use gj and gk.
3. The cursor jumps back to where it was before you made the mouse move.

Expected result

Expect that gj and gk operate from where the cursor is, regardless of how it go

Actual result

A gif of the behaviour in the Sandbox Vault. Version 1.0.1 (Installer 1.0.0).

(I show two different locations to illustrate it is not related to lines with blank lines between them.)

Environment

• Operating system:

• Debug info:

---

Additional information

Related bug, where I first mentioned this behaviour:

Vim hotkeys `gj`, `gk` are broken in 1.0.0

2 standard vim commands: gk and gj (usually mapped to k and j respectively using obsidian-vimrc-support) are broken in 1.0.0 but not 0.15.9. This makes scrolling through documents containing long sentences very inconvenient, at least for me and others who use this binding. Steps to reproduce Install 1.0.0 Enable vim support Use the key chord gk or gj Expected result gj moves cursor down a single visual line of text, rather than a markdown to the end of a markdown sentence. Vice versa fo…

Vim hotkeys `gj`, `gk` are broken in 1.0.0

I don’t use that plugin. But I do notice that it does seem to be offset, based on characters or Markdown format. My theory is that it moves vertically, but then gets shifted based on Live Preview expanding the Markdown. Does seem like potentially the randomness you are experiencing? In these tests, I am only using gj and gk, and moving up and down changes where I end up on the first time, and then returns to where it was on the 2nd time. [vimGJGK] Even when I switch to Source Mode, the font …

[WhiteNoise]

is this fixed in 1.0.3?

[pmbauer]

I was unable to repro in 1.0.3