Vscode-neovim: Inputting too quickly after exiting insert mode causes desync

[chaorace]

Exiting insert mode and attempting to navigate too quickly causes the neovim and vscode buffers to de-synchronize. I happen to have the escape key bound to my home row, so I've been able to consistently trigger this bug.

Demonstration: https://giant.gfycat.com/WaryFamousBoto.webm

I started experiencing this bug a couple days ago, not sure of the exact date, unfortunately. I can confirm this issue is reproducing with all neovim plugins disabled. I am using plugin version v0.0.52

This is my current neovim version string (nightly from 1 day ago, issues predate any recent upgrade):

NVIM v0.5.0-635-g8c49e3d50
Build type: RelWithDebInfo
LuaJIT 2.0.5
Compilation: /usr/bin/cc -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=always -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/home/chao/.cache/yay/neovim-nightly-git/src/build/config -I/home/chao/.cache/yay/neovim-nightly-git/src/neovim-nightly-git/src -I/usr/include -I/home/chao/.cache/yay/neovim-nightly-git/src/build/src/nvim/auto -I/home/chao/.cache/yay/neovim-nightly-git/src/build/include
Compiled by chao@manjaro-desktop

This is my VSCode version string:

Version: 1.47.3
Commit: 91899dcef7b8110878ea59626991a18c8a6a1b3e
Date: 2020-07-30T16:19:47.070Z
Electron: 7.1.14
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Linux x64 5.7.9-1-MANJARO

[asvetliakov]

with all neovim plugins disabled.

Does it happen with empty init.vim as well?

[wtfuzz]

I'm experiencing the same behaviour using v0.0.52 on OSX. If I exit edit mode and hit a key too quickly, I have to close and re-open the file or switch tabs to make it respond.

$ nvim --version
NVIM v0.5.0-nightly
Build type: Release
LuaJIT 2.0.5

Version: 1.48.1
Commit: 3dd905126b34dcd4de81fa624eb3a8cbe7485f13
Date: 2020-08-19T17:09:41.484Z (5 days ago)
Electron: 7.3.2
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 19.4.0

I also get a notification popup

[chaorace]

@asvetliakov I'm actually using my init.vim to work around a different (tabstop related) desync issue (see PR #307), so I can't effectively test if this desync issue persists when it's outright disabled.

I assure you that it's quite threadbare, see below:

call plug#begin(stdpath('data') . '/plugged')

Plug 'tpope/vim-surround'
Plug 'kana/vim-textobj-user' | Plug 'kana/vim-textobj-line'

call plug#end()

set clipboard+=unnamedplus

if exists('g:vscode')
   set tabstop=2
else

endif

[asvetliakov]

Your init.vim is OK

i guess it's some racing/delay because there is more work now when extension exits the insert mode. I'll look into a way how to improve this. In meantime you can revert to 0.0.50 if this bothers you much.

@chaorace do you have any errors similar @wtfuzz one?

[theol0403]

I've had this problem with 0.0.50 as well, but in a seemingly more minor form.
I haven't had any errors/notifications or anything, just a little extra character in the vscode buffer that isn't in the nvim buffer. Usually, u<C-R> is enough to get it back in sync.

[chaorace]

@asvetliakov No such error prompts on my end. The dev console is also error-free.

After reverting to v0.0.50, I can also verify that the issue seems to have been introduced with release v0.0.52

[theol0403]

I'm not sure if my issue is exactly what you are having (the desync for me isn't awful), but here is a gif of my issue on v0.0.50 with empty init.vim, where kj is my escape mapping.

[asvetliakov]

Try attached version (rename ext to vsix) and check if it helps with it. built from #326 PR

vscode-neovim-0.0.53.zip

[chaorace]

Seems to be working for me so far, I can no longer reproduce using the given PR. I'll continue to use it and will report back if I encounter any new issues that seem to be coming from the new changes.

[theol0403]

I think it has improved it for me as well, I can't reproduce it using <esc> and exiting from insert mode seems snappier.
However, I can still cause the buffer desync if I do kbj in rapid succession - it inserts "b" and then exits insert mode. Maybe there are two problems here.

[asvetliakov]

@theol0403 that's another issue, second composite key handler doesn't check if you've typed another character between first & second escape keys. Should be easy to fix

[chaorace]

I question if the current behavior is even consistent with vim's chording mechanism. Wouldn't it make more sense to reject a 'jk' key chord if it's interrupted instead of trying to salvage the interrupting keystrokes?

[wtfuzz]

@asvetliakov I'm not able to reproduce the issues I was having with the 0.0.53 build

[theol0403]

After using this build for a bit, I've found another issue: in big files, when exiting insert mode, dot-repeating an insert, or doing any sort of buffer manipulation (for example cs]} with vim-surround), the buffer is sometimes really slow and unresponsive and then I notice my language sever is indexing while vim is unresponsive.

I'm not sure if this is all one problem, but I can definitely confirm that when sometimes exiting insert mode and always when running dot-repeat, all input freezes and everything is slow while the language server parses things.

Just confirmed this is actually a problem with the 0.0.53 build, and not just this fix. Basically, doing any action in a file that has some language server that likes to do indexes on buffer changes causes the buffer and input to slow to a crawl during the buffer manipulation.

Edit:
Sorry, disregard this, I'm no longer sure what the problem is. It seems to be that the buffer crawls to a halt when the language server does semantic highlighting, which messes up nvim, but this actually also happens in 0.0.52. I'll make a proper issue if I pinpoint a related problem, but I had just originally thought that the rebinding of type commands caused the plugin to wait until the LSP was done before accepting any more input.

[scalavision]

I have the same problem, tried reverting to the old 0.0.50, then nothing works ... Hope it is possible to fix this, feels like doing everything at half speed without this plugin :-)

[asvetliakov]

@scalavision Try 0.0.53 build above

[asvetliakov]

@theol0403 subscribe to #330 for kbj problem