dot repeat restores wrong cursor position

[max397574]

when I do for example ysiw" and then go to any other location and . the cursor jumps to the position it had when executing the keybind ysiw" I set move_cursor to false

[kylechui]

Just as a note: this might not be fixed until #113 is merged, since that branch has quite a few breaking changes and major restructuring.

Note to self: The . operator directly calls normal_callback with the text-object already loaded, so the cursor position cannot be saved from there. Need to find a way to find the most recent cursor position, similar to vim.v.operator or vim.fn.visualmode().

[kylechui]

Hmm... doing a bit more thinking, I'm not actually 100% sure this is possible to remedy with the current structure of the code

[kylechui]

This might actually be incompatible with automatic indentation, at least if this upstream feature doesn't get added.

[max397574]

afaict this is fixed @kylechui did you add a commit which should have fixed it or am I just doing sth differently?

[kylechui]

I made zero conscious changes, but glad to know it's fixed(?) Feel free to close the issue if you feel that it's good, and reopen if necessary

[chrisgrieser]

I am on the latest commit and noticed the very same behavior: dot repeats move me to the original position.

[windowsrefund]

same behavior seen after updating to the latest.

[kylechui]

Indeed, no fix has been made (nor do I believe that a fix is possible as of right now). I remain open to any ideas or suggestions.

[kylechui]

As a note to myself and anyone curious about the root issue: When the . command is activated, an operatorfunc is called with the prior motion, which immediately modifies the cursor's position. Thus by the time the code inside the operatorfunc is called, the original cursor position is lost and cannot be cached. The only way I can think to fix this is for user-inputted motions to be processed by the plugin itself, and then "replayed" when . is triggered. However, this would break extensibility, since all of the motions would somehow need to be hard-coded in, and motions defined by other plugins (e.g. targets.vim or nvim-treesitter-textobjects) would not be processed properly.

[kylechui]

Hey all, this should be properly fixed now, please take some time to try it out! Big thanks to @ribru17 for the help and implementation.

[chrisgrieser]

can confirm, issue appears to be fixed. Thanks! 😊

[ribru17]

Awesome, thanks Kyle!!