vscode-neovim: Inputting too quickly after exiting insert mode causes desync
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
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 17 (10 by maintainers)
@scalavision Try 0.0.53 build above
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 subscribe to #330 for
kbjproblemAfter 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.
@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 releasev0.0.52