nvim-surround icon indicating copy to clipboard operation
nvim-surround copied to clipboard

dot repeat restores wrong cursor position

Open max397574 opened this issue 1 year ago • 3 comments

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

max397574 avatar Jul 26 '22 14:07 max397574

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 avatar Jul 26 '22 21:07 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 avatar Jul 27 '22 21:07 kylechui

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

kylechui avatar Aug 01 '22 01:08 kylechui

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

max397574 avatar Nov 03 '22 06:11 max397574

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

kylechui avatar Nov 03 '22 06:11 kylechui

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

chrisgrieser avatar Dec 11 '22 18:12 chrisgrieser

same behavior seen after updating to the latest.

windowsrefund avatar Jun 07 '23 03:06 windowsrefund

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 avatar Jun 07 '23 05:06 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 avatar Jun 08 '23 23:06 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.

kylechui avatar Aug 05 '23 20:08 kylechui

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

chrisgrieser avatar Aug 05 '23 23:08 chrisgrieser

Awesome, thanks Kyle!!

ribru17 avatar Aug 06 '23 03:08 ribru17