Closed MaciekChudek closed 4 months ago
I confirm the bug. Thanks for reporting it! Did you try R_assign=1
? It seems to have the same bug. Could you make a pull request fixing it, please?
I had a play around with it. The R_assign = 2
case with a single underscore (i.e., no replacement) is easy to fix by performing the check for a preceding underscore before dropping out of insert mode. I'll create a pull request.
The more general R_assign = 1
is harder. I can't see an obvious fix. You need to drop into normal mode to call the ReplaceUnderS() function, which resets the @. register, used for dot-repeating. That register is read-only, so we can't just restore what was in it previously. I checked and the other plugin I use for replacement in insert mode (vsnip) has the same problem.
Possible solutions could be to rewrite the replacement functions so they never leave insert mode, or delete the entire typed text and reinsert it followed by <-. Both options feel kludgy and laborious to implement. Since no-one but me has ever complained about this issue, I don't think it's worth the time to fix.
I have never noted this bug because I rarely use Vim's dot-repeat, and you are the first to report it since May 2009. I'll wait for the pull request. Thank you!
You can fix only the R_assign = 2
and let the other case be fixed by someone else in the future.
Repeatable example:
I'm guessing that while waiting for the second underscore, nvim-r erases the change buffer but doesn't restore it when the next character isn't an underscore. This breaks the basic vim dot-repeat functionality.