Vscode-neovim: [vim-repeat] insert mode

[mkitt]

Hello.

Given the following invalid JSON (it's missing the EOL commas ,):

{
  "line1": "1"
  "line2": "2"
  "line3": "3"
  "line4": "4"
}

In Vim with the vim-repeat plugin, if I type the following sequence on "line1" to insert the comma at the end of the line:

A,ESC

Then I move down to "line2" and type the . and then down to "line3" and type the . again it will repeat and insert the comma at the end of each of those lines. It doesn't seem like this behavior is currently working in vscode-neovim.

Other vim-repeat behaviors including those coupled with vim-surround like cs"' work fine. I would assume the issue is related to switching over to insert mode and VSCode taking back control?

I've got 🤞 the solution doesn't require listening to events in insert mode as from a few other issues that sounds like a non-starter due to performance reasons.

Thanks for the hard work on this project!

[asvetliakov]

Yes, anything involving insert mode is tricky. You can try to use macros (q<reg>) (you can repeat last macro with @@ if you don't know already) - these are treated specially and working with insert mode too.
Also another solution to solve this particular problem - visual line mode and A - should produce you multiple cursors at the end of each line

Generally i think i'll evolve multiple-cursors supports rather than trying to workaround insert mode

[mkitt]

Yeah there's lots of ways to work around the specific use case I described above and macros are a great way to achieve that. Thanks for that tip. I was generally referring to the case of being able to "repeat the last inserted text" with the . operator no matter what that insertion is.

While evolving multiple cursor support will go a long way, I've found the . operator to be far more powerful for a lot of the reasons described in this article and particularly around the cgn command.

I completely understand and appreciate the reluctance to get involved with insert mode. Feel free to close this issue if repeating the last inserted text isn't something vscode-neovim will support.

Thanks again!

[asvetliakov]

Something like cgn i'd want to support. What do you think if it (. for repeat last insert text) will be bound to different key? Because i support <C-a> for the insert mode (by using '[ and '] marks), i think similar thing could be achieved for cgn followed by different key (e.g. <leader>.) and similar

[mkitt]

Binding to another key like <C.> or <leader>. could work, especially in the short term. It'll always feel a little weird since dgn does work as expected with the . operator though. It might be worth the trade off since it seems like the alternative would be to listen to events while in insert mode.

[justinmk]

What do you think if it (. for repeat last insert text) will be bound to different key?

I hope we can avoid that. What about letting Nvim control insert-mode when insert-mode is entered via operating-pending? That is, VScode should control insert-mode when user invokes i or a by itself, but otherwise let Nvim control it.

[asvetliakov]

@justinmk
Interesting... haven't though about operator pending mode. What to do with things like cc ? it's very common operation to start insert mode and continue adding new lines further

[justinmk]

Yeah, it's probably too janky to have two different approaches. Better idea: if the text inserted by vcode were sent to Nvim as an edit instead of just syncing the buffer, the problem would go away. The plumbing needed for this is not in Nvim yet (though I'm working on it). Might be better to wait until then. I do miss dot-repeat for inserts in this plugin, so maybe that will hurry me :)

[asvetliakov]

@justinmk Hell yeah, that would be great! also an option to not create undo point (currently each nvim_buf_set_lines call creates undo point even if nvim is in insert mode, (thats why i'm sending text to nvim only after exiting the insert mode)) won't hurt as well. Also need an option to control whether such change should be treated as edit or not (for things like auto-imports - you obviously don't want them to be repeated 😄 (or just filter them based on current cursor position))

[michael-go]

Not sure it's related but I think it is 🙈

Without any special plugins, the . doesn't work for me as expected. I'm used to doing search replace with . by:

• hitting shift-* on a word I want to replace
• then doing cw, typing the replacement, and hitting ESC
• then hitting n to go next match, and type . where I want to replace again.

The problem is that instead of replacing when hitting . it just removes the underlying word (like it repeats the cw but not what follows.)

thanks

[asvetliakov]

Same issue - vim doesn't receive edits from insert mode

Also may be working workaround - before doing cw or cgn - insert macro recording mode (qa or similar), then exit after editing. This way . works, you don't need even to execute the macro. I think you can bind own keys/write function to do it automatically and use something like rw/rgn (example)

[michael-go]

Thanks @asvetliakov. qa did help with the search replace. 🙏

[paldepind]

@justinmk

Better idea: if the text inserted by vcode were sent to Nvim as an edit instead of just syncing the buffer, the problem would go away. The plumbing needed for this is not in Nvim yet (though I'm working on it). Might be better to wait until then.

Is there an open Neovim issue one can track for that addition? I think the promise of this VSCode plugin is amazing but unfortunately, with this issue present, it completely breaks at least my Vim workflow.

[alicederyn]

Same as paldepind — I'd love to use this extension but . is just hard-coded into my brain at this point.

[asvetliakov]

I think i have a workaround for this, follow #160 PR

[wis]

since the dot (repeat insert) doesn't work I tried nmapping dot to ctrl-a

if !exists('g:vscode')
  nnoremap . i<C-a>
endif

but it didn't work, so instead of that, which of the helper functions can I use to call ctrlAInsert from init.vim?

[asvetliakov]

@wis
Ctrl-a is implemented by using '[ and '] marks

I'd suggest to wait a little bit more - the new PR will fix all dot-repeat things

[asvetliakov]

For anyone interested here is test version (rename to vsix and install it through Install from VSIX in vscode):

vscode-neovim-0.0.51.zip

Far from ideal but basic repeating should be supported

[davidovich]

This works for me so far. Thanks for all your work!

[luisherranz]

Works here as well! 🎉

[erezsh]

This is a big usability issue imho. I was about to give up and go back to vsvim, when I found this issue. Maybe you should make a release?

[willzhqiang]

Thanks for some tips, at least I am happy with macro and multiple cursor to replace dot function currently.