bug: plugin changes j/k behavior

[hneutr]

Neovim version (nvim -v)

0.10.1

Neovim distribution

N/A

Operating system

MacOS

Terminal emulator / GUI

kitty

Describe the bug

The plugin changes the behavior of the j and k normal mode movements.

1. put the cursor at the end of a long line (without using $; the behavior is as expected if $ is used, weirdly)
2. move the cursor down (or up) to a shorter line
3. move the cursor back up (or down) to the longer line

If the long line is length X and the short line is length Y, the cursor will be at column Y of the long line, rather than at column X as expected. In other words, j and k are not inverses.

A more visual explanation:

If the buffer contains the following text, and the cursor is on the character surrounded by brackets:

short line
longer lin[e]

press k

short lin[e]
longer line

press j

short line
longer li[n]e

In other words, the plugin "column memory" of j/k is getting messed with

Expected behavior

start:

short line
longer lin[e]

press k

short lin[e]
longer line

press j

short line
longer lin[e]

Healthcheck output

render-markdown: require("render-markdown.health").check()

render-markdown.nvim [version] ~

• OK plugin 7.1.15
• OK neovim >= 0.10

render-markdown.nvim [configuration] ~

• ERROR render-markdown.code.position: expected one of { "left", "right" }, got

render-markdown.nvim [nvim-treesitter] ~

• OK installed
• OK markdown: parser installed
• OK markdown: highlight enabled
• OK markdown_inline: parser installed
• OK markdown_inline: highlight enabled
• OK latex: parser installed

render-markdown.nvim [executables] ~

• WARNING latex2text: not installed
  • ADVICE:
    • Disable LaTeX support to avoid this warning by setting { latex = { enabled = false } }

render-markdown.nvim [conflicts] ~

• OK headlines: not installed
• OK obsidian: not installed

Plugin configuration

Reproducible with no configuration

Plugin error log

N/A

Confirmations

• I have updated this plugin to the latest version using my plugin manager
• I have provided text for all screenshots & understand that my issue will be closed if I have not

Additional information

No response

[MeanderingProgrammer]

Thanks for reporting this!

At first I thought there was no way it was due to this plugin since we don't track any kind of column state or touch motions at all. But after disabling the plugin and trying a few things it was definitely something I was doing.

Turned out to be related to the constant setting of window local options. While setting the values doesn't seem to have a noticeable performance penalty and I figured internally neovim would do nothing if we were reseting the same value, that did not appear to be the case. There could be a very good reason to still do some work when setting an option even if it's the same value and something about that messed with this column state.

Fix was pretty simple on my end and the plugin now checks if the value being set is different than the current value: 91ce0b5

LMK if it works on your end!

[hneutr]

Yeah hah, I really did not expect it to be coming from this plugin when I was doing the ol "disable plugins one by one and see where it's coming from" search. Went digging in the plugin code to see where it might be coming from and didn't find any likely culprits, either. But dang, window local options side effects, now that wouldn't have been my first, second, or third guess — that is some impressive sleuthing on your end.

Fix works like a charm 💫. Thank you!