This extension is great. I like that I can use real vim while interfacing w/ VS Code but I had a difficult time figuring out how to exit insert mode because the Escape key does nothing by default. The Ctrl + C mentioned in the README.md did not pop out at me when I was reading about the extension and it took a while to figure out how to add the Escape key binding.
I'm curious, why bind Ctrl + C to <Esc> rather than binding Escape to <Esc>? I ended up working around this by adding this to my keybindings:
{"key": "Escape", "command": "vscode-neovim.escape" }
I figure there's probably a good reason why you did not use the default key for <Esc> I'm just curious as to why.
Thank you for your feedback. Perhaps you're right. Probably i shouldn't have put the ctrl+c as default escape key binding (although it's valid VIM escape key by default too, but behaves slightly different than Esc in few situations).
The main reason is the Esc key is used in vscode to cancel/abort many things and i just didn't have a time to test it properly
I'll test and add Esc as second escape keybinding for next release
I'll test and add
Escas second escape keybinding for next release
Any objection to also add ctrl-[ ? This is a Vi/Vim builtin ESC alias, and it's what I (and many others) use. (I configured it for myself locally, but it would be good to have it by default.)
@asvetliakov BTW, really great work on this extension! It's a huge relief coming from VScodevim (which had really bad performance/undo/etc. bugs).
Any chance this can be modified with Neovim's init.vim file? I usually use jj with a timeoutlen of 250 ms.
Any chance this can be modified with Neovim's init.vim file? I usually use
jjwith atimeoutlenof 250 ms.
That was my follow up question but I figured I should create a separate issue.
I tried repeating my init.vim by entering inoremap jj <Esc> in the command menu but that doesn't seem to work.
Probably i shouldn't have put the ctrl+c as default escape key binding (although it's valid VIM escape key by default too, but behaves slightly different than Esc in few situations).
haha Good to know! I have used vim for years but I only know the keys / commands that I use regularly. I did not know about ctrl+c (I assumed that bash would interpret this before vim does) or ctrl+[
@justinmk Thank you for making this possible! no, nothing is preventing of adding ctrl-[ as well, thanks for catch
@bad5ect0r
@gforceg
this isn't that you would want to hear but jj and jk are not supported as any insert mode mappings. And won't be. See #70 , #52 for context
I guess it's something worth getting used to if you want to use this plugin. Will change my regular vim files to also use Ctrl-C.
@bad5ect0r
I'm mapping caps lock to ctrl-c (since the old time when i had been using emacs). Many are mapping caps lock to esc too. This may help to reduce your finger stress.
@bad5ect0r per @bogdan0083 in issue #52 it looks like you can add the following to your keybindings json:
{
"key": "j j",
"command": "vscode-neovim.escape",
"when": "editorTextFocus && neovim.mode == insert"
}
The only downside here is that I think you have to add such an entry for each mapping in init.vim.
Scratch that! I should have read the rest of his post. The when section doesn't seem to prevent vs code from listening for a chord after the first j is typed.
@gforceg @bad5ect0r I may have one idea how to make jj (but not jk!) work without sacrificing insert mode performance (#75)
So does that mean that a good neovim-ESC keybindings.json would be:
[
// https://github.com/asvetliakov/vscode-neovim/issues/74
{"key": "Escape", "command": "vscode-neovim.escape", "when": "editorTextFocus && neovim.mode == insert"}
]
This wouldn't run if I disabled or removed vscode-neovim, right?
Is the editorTextFocus even needed?
Yes, correct
This wouldn't run if I disabled or removed vscode-neovim, right?
I haven't tested, but I think neovim.mode check should prevent running this command (it'll be undefined) if you have removed the extension.
Is the editorTextFocus even needed?
Yes. Otherwise you might get strange effects when focused out from the editor, e.g focused in file explorer
I'd greatly appreciate if you would investigate a solution compatible for both jk and jj from the get go. Also, multiple bindings should be supported as well. I use both jk and regular ESC for example.
Mode switching is too important to ignore any of the major solutions/combinations out there. I'd go so far as to say it's a dealbreaker.
@docwhat A better keybinding is:
[
{
"key": "Escape",
"command": "vscode-neovim.escape",
"when": "editorTextFocus && neovim.mode != normal"
}
]
Pressing Esc in any mode other than "normal" should take us out of that mode.
A little off-topic, but these should probably be added as well:
json
{
"key": "ctrl+n",
"command": "selectNextSuggestion",
"when": "suggestWidgetMultipleSuggestions && suggestWidgetVisible && textInputFocus"
},
{
"key": "ctrl+p",
"command": "selectPrevSuggestion",
"when": "suggestWidgetMultipleSuggestions && suggestWidgetVisible && textInputFocus"
},
{
"key": "ctrl+n",
"command": "workbench.action.quickOpenSelectNext",
"when": "!editorFocus"
},
{
"key": "ctrl+p",
"command": "workbench.action.quickOpenSelectPrevious",
"when": "!editorFocus"
}
So I can use ctrl+n & ctrl+p for selecting code suggestions and to select options in ctrl+p-derived menus.
It makes sense to me to have defaults for anything that works in neovim, which includes Escape, ctrl-[, and maybe ctrl-c
At least explain how to specify a different keybinding in the README. Not being as familiar with vscode plugin architecture, I assumed vscode-neovim.escape was a setting I had to set to "Esc" or something, not a command to attach to a keybinding.
Thanks a lot! This puzzled me for a big while. I didn't see the added instruction in the README. Maybe a newer version is not released yet? Would it be good to keep this issue open until a newer version is available?
@pluskid
The Esc along with other escape keys (C-[, jj/jk) were added & released a while ago
Most helpful comment
@docwhat A better keybinding is:
Pressing Esc in any mode other than "normal" should take us out of that mode.