Personally, my problem with trying to use Vim keybindings in VS Code is not about the motions of moving around/editing the code itself, but everything else. You end up in plenty of situations where you have to resolve using the mouse because you ended up on some sub-page or whatever, where you either need to resolve using the mouse or keep pressing Tab until you get to where you want to go.
Installing plugins is one good example of this, where even if you use a Vim plugin (or this, it seems), you still need to resolve to using the mouse/Tabbing to actually install the plugin itself.
While with Neo/Vim itself, you never need to reach for the mouse, because the entire thing, not just the editing/writing, is meant to facilitate keyboard-only usage.
I do now have memorized some mix of vim and vscode keybindings, but to me it's worth it. I'm not at 100% keyboard navigation because in some cases I've burned 5-10 minutes looking up a shortcut, repeatedly 1/mo for 3 months. After so many (overly) spaced repetitions, I recognize the shortcut isn't worth memorizing.
> Installing plugins is one good example of this, where even if you use a Vim plugin (or this, it seems), you still need to resolve to using the mouse/Tabbing to actually install the plugin itself.
I agree with you here, but I rarely need to install new plugins. It's certainly not a task I repeat for a given plugin. Plugins are actually the reason I do primary development in VSCode instead of Neovim natively. I can set up linters, language highlighters, etc in VSCode much faster than I can in Neovim. The ecosystem in VSCode also seems to be bigger for what I've done in the last few years.
---
Anyways, here are some VS Code keybindings I've found essential to go hand-in-hand with vscode-neovim. These few probably get me to 90% keyboard navigation for day-to-day editing.
cmd-shift-m: toggle the bottom tray problems (works as a universal way to show/hide the bottom)
cmd-b: toggle the left sidebar (in whatever context it was last in)
cmd-shift-e: show the current file in the left sidebar
cmd-0: move context/focus to the left sidebar
cmd-1: move context/focus to the editor
cmd-2: move context/focus to the right editor (or open an editor split, if not yet split)
ctrl-1,...9: highlight Nth tab from the left
ctrl-0: highlight rightmost tab
cmd-p: fuzzy find file
cmd-shift-p: fuzzy find any installed action by description
I guess I am the target market. I don't mind using the mouse when I'm not in the "flow" of editing. Even browsing code, scroll wheels are pretty expressive, and clicking to jump to definition is fine. Ok not typing, so I don't need to keep my hand on the home row.
>Installing plugins is one good example of this, where even if you use a Vim plugin (or this, it seems), you still need to resolve to using the mouse/Tabbing to actually install the plugin itself.
Sounds like a minor annoyance at best... Where vim-mode is important to me is editing and navigating code, not when installing plugins...
It's not just installing plugins. It's the VCS view, the symbol list, the terminal, the file browser, the search pane, the debugger pane, any pane added by any extension, etc.
Ctrl+shift+p puts the cursor in the command search where you can find all the commands including extension related commands. Ctrl+w j puts the cursor in the terminal.
VS code is entirely navigable with key strokes even with Vim emulator
As mentioned, extensions is one example. How do you resize the sidebar? Or resizing the vertical size of the "Outline" pane?
To be honest, guess it was a long time ago I last used VS Code, but when I did, I ended up in situations where it wasn't suitable to use the keyboard too many times.
It allows you to execute arbitrary VScode commands in fewer keystrokes using Emacs like menu (never used Emacs myself, so might be off a little).
Along with default <space> key, I've also mapped ctrl+g as a global binding to trigger VspaceCode. So almost anywhere in the UI, I can always use keyboard to navigate.
>>While with Neo/Vim itself, you never need to reach for the mouse, because the entire thing, not just the editing/writing, is meant to facilitate keyboard-only usage.
Exactly, most python plugins like black, code formatters, auto complete etc don't even work with these plugins.
That is the reason why I moved from eMacs to neovim. Emacs on itself is amazing piece of software, but I had to fight my way to setup vim binding on everything.
With neovim you just get that by default. Everything is thought around that.
perhaps onivim would be a good VSCode alternative for you, I think they have a mode like the browser vim extensions that labels everything on screen with a key you can press instead of clicking.
I don't use VSCode, but if you use this plugin or the other Vim plugin for VSCode, make sure to put it in its own thread so it doesn't compete with other blocking tasks and slow down your editor motions.
It's new within the last year for sure! It's also marked "experimental" and I think therefore not heavily advertised, but IMO it's also necessary for something like Vim motions that need to move at the speed with which you type…
I have used VSCode-Neovim on OSX since roughly NVIM v0.5. It is quite simply the best vim environment I've ever used and I've used quite a few. I date myself back to vim, back to vi and even to TECO. I pair this setup with the clangd LSP extension which makes it even more awesome. This is editor heaven.
However it isn't perfect, yet. Command mode is still a work in progress and I use command mode a lot. Navigation with the space bar screws up enough that I've switched to the arrow keys (which are smaller). A few others but I haven't checked to see if they're fixed already.
VSCode-Neovim is actively worked on and gets better with each release.
My biggest complaint is probably that it doesn't support overlay or popup windows, which makes it impossible to use plugins like WhichKey[0] and such, which I like on normal neovim because I'm a scrub and don't know vim hotkeys by heart
Whenever I didn't know how to do something or suspected there'd be a far more efficient way to go about it, I'd look up the magic words or keys to use and write them down.
Limiting this cheatsheet to just one side of an A4 sheet kept it usable and forced me to rewrite it every so often - every next iteration leaving off all the commands I had been checking back often enough for that they had finally stuck.
Completely unsolicited, but hopefully useful advise nevertheless :)
The beauty of the whichkey/space menu is that you can both learn shortcuts AND find new ones (they're grouped by domain) AND find old shortcuts you rarely use.
It's the antidote to most sophisticated editors worst problem, that there's a bajillion commands scattered around a million menus, many of which are not even remotely intuitive.
Would love to see if people have a good experience with this. The only thing keeping me on neovim is the ergonomics of my config. If I can have that, PLUS the discoverability of all the LSP features, hovering, consolidated error messages, etc. without it breaking all the time, I would switch in a heartbeat.
FYI: LunarVim is a neovim config that integrates all the LSP and treesitter stuff. I've been using it for around 6 months now and am loving it. However, I'll admit that I went into it looking for a vim config that would allow me to ditch the vi configs I had been carting around for decades, including a lot of half working plugins, so I've tried to modify the stock LunarVim configs as much as possible. So it'll depend on how much of the ergonomics of your config is based on customizations, YMMV.
Have you tried coc.nvim? I was in the same boat as you, trying to painlessly move away to a different editor with Vim keybindings or such, because I just couldn't get LSP stuff to work without constantly breaking. Since I started using Coc, it all just works magically, I just need a `:CocInstall` if I'm working in a new language.
This. I've been all over Coc since it showed up. It's pretty good. So much so that I've not yet even bothered to look at the native support that came later.
I find that on the whole it's much speedier, albeit a tad buggier, than the “official” vim extension. I think in another year it will be more or less perfect.
If you're talking about keeping your Neovim config: yes, due to the Neovim extension using the actual Neovim program (this was one of the new Neovim features: it includes a vim server that processes keystrokes and sends updates for use in a different UI). So it has no problem reading your vim config at startup.
For unrelated reasons I've gone back to neovim. But I used this in vscode for about a year. It works well. I found it got stuck once a day or so and I had to restart vscode. That might have improved by now. Having your keybinding-related config spread out across so many different places (nvim's config, vscode's preferences and keybinding files) is a bit annoying, and I found after initial setup I kept forgetting what was where. And then whatever vi plugin you use, vscode is never going to be entirely consistent about keybindings outside of the main editing panes.
Those relatively minor annoyances aside, vscode-neovim is perfectly workable for daily use.
I know those times you're talking about when it gets stuck. Switching to another file and back seems to solve that issue for me, and is much faster than a restart.
I actually do use pane commands from time to time.
ctrl-w s : will split horizontally
ctrl-w v : will split vertically
Commands work, and I just tested buffers specifically. I can type :buffers and I see a list. I was able to get vscode to switch tabs with :b 209 (I don't normally inspect buffers this way, but it's integrated and it works).
The discussion of Vim visual mode selections being separate from VSCode selections is concerning. What kind of selection is produced if you make a selection using the mouse? Are there any actions where you can end up with the wrong type of selection?
You might be able to convince me that for certain languages and tasks, a Jetbrains editor is better than using a plugged up Vim or Emacs. And the up front cost is well known, and their corporate model is easy to understand.
You’ll never convince me, however, that Microsoft’s embrace, extend, extinguish partially proprietary editor that uses the same LSPs as any other LSP client should be used by anyone. I wouldn’t touch it with a 100 foot pole.
There are turn key solutions for both Emac, Vim, and Neovim. They can all talk to LSPs, have DAP clients, fuzzy finders, file tree explorers, project managers, remote editing (terminal editors are by nature the ultimate remote editors).
Why isn’t he world would you put neovim inside of VSCode when you could just use neovim directly via GUI or terminal.
Don't, no one's forcing you, but many if not most people prefer VSCode over neo/vim, based on usage stats. For those of us that do, we like Vim's modal editing but not its setup process.
I love neovim but I don’t have a good replacement for the git plugin of vscode. I haven’t found my way to replicating that experience in neovim. I tried lazygit but I find the diff viewer hard to understand and navigate. Diff view (https://github.com/sindrets/diffview.nvim) might be it, but I haven’t made the time to install a newer version of git from source (Debian…)
Besides showing the git signs in the gutter, it can do staging, diffing, navigation between hunks, line blame, can show deleted lines etc. If you have more advanced workflows, it might not be enough though. I use lazygit quite often as well.
vim-fugitive is ergonomically great for routine stages and commits.
DiffView is good but there's no point denying GUI diff viewers are better than text ones, so I use one (meld or sublime-merge), which does mean launching a separate tool. That's fine for my limited uses (quick visual overviews, or fixing merge conflicts).
I'm the same. For the most part, I use a nice terminal git diff (I forget which-- not in neovim), and I hop around in neovim based on what I see there. I do sometimes open Codium just to navigate a large diff, and it always makes me a little sad.
Similarly, I use diff-highlight 99% of the time because it works flawlessly with all of git diff's arguments (including --word-diff) but break out Meld for big content-heavy changes.
Readit News
Installing plugins is one good example of this, where even if you use a Vim plugin (or this, it seems), you still need to resolve to using the mouse/Tabbing to actually install the plugin itself.
While with Neo/Vim itself, you never need to reach for the mouse, because the entire thing, not just the editing/writing, is meant to facilitate keyboard-only usage.
> Installing plugins is one good example of this, where even if you use a Vim plugin (or this, it seems), you still need to resolve to using the mouse/Tabbing to actually install the plugin itself.
I agree with you here, but I rarely need to install new plugins. It's certainly not a task I repeat for a given plugin. Plugins are actually the reason I do primary development in VSCode instead of Neovim natively. I can set up linters, language highlighters, etc in VSCode much faster than I can in Neovim. The ecosystem in VSCode also seems to be bigger for what I've done in the last few years.
---
Anyways, here are some VS Code keybindings I've found essential to go hand-in-hand with vscode-neovim. These few probably get me to 90% keyboard navigation for day-to-day editing.
cmd-shift-m: toggle the bottom tray problems (works as a universal way to show/hide the bottom)
cmd-b: toggle the left sidebar (in whatever context it was last in)
cmd-shift-e: show the current file in the left sidebar
cmd-0: move context/focus to the left sidebar cmd-1: move context/focus to the editor cmd-2: move context/focus to the right editor (or open an editor split, if not yet split)
ctrl-1,...9: highlight Nth tab from the left ctrl-0: highlight rightmost tab
cmd-p: fuzzy find file cmd-shift-p: fuzzy find any installed action by description
But the actual editing doesn't use the mouse.
gd (go to definition)
You'll also like
gh (peek definition)
Sounds like a minor annoyance at best... Where vim-mode is important to me is editing and navigating code, not when installing plugins...
VS code is entirely navigable with key strokes even with Vim emulator
To be honest, guess it was a long time ago I last used VS Code, but when I did, I ended up in situations where it wasn't suitable to use the keyboard too many times.
That includes mouse wheel, clicking tabs, resizing windows, balloon help amongst others.
That works over SSH too.
It allows you to execute arbitrary VScode commands in fewer keystrokes using Emacs like menu (never used Emacs myself, so might be off a little). Along with default <space> key, I've also mapped ctrl+g as a global binding to trigger VspaceCode. So almost anywhere in the UI, I can always use keyboard to navigate.
EDIT: formatting
Exactly, most python plugins like black, code formatters, auto complete etc don't even work with these plugins.
With neovim you just get that by default. Everything is thought around that.
https://onivim.io/
See "Affinity" docs here for putting it in its own thread: https://github.com/vscode-neovim/vscode-neovim#installation
However it isn't perfect, yet. Command mode is still a work in progress and I use command mode a lot. Navigation with the space bar screws up enough that I've switched to the arrow keys (which are smaller). A few others but I haven't checked to see if they're fixed already.
VSCode-Neovim is actively worked on and gets better with each release.
0: https://github.com/folke/which-key.nvim
Limiting this cheatsheet to just one side of an A4 sheet kept it usable and forced me to rewrite it every so often - every next iteration leaving off all the commands I had been checking back often enough for that they had finally stuck.
Completely unsolicited, but hopefully useful advise nevertheless :)
It's the antidote to most sophisticated editors worst problem, that there's a bajillion commands scattered around a million menus, many of which are not even remotely intuitive.
If you're talking about keeping your Neovim config: yes, due to the Neovim extension using the actual Neovim program (this was one of the new Neovim features: it includes a vim server that processes keystrokes and sends updates for use in a different UI). So it has no problem reading your vim config at startup.
Those relatively minor annoyances aside, vscode-neovim is perfectly workable for daily use.
You don't get the "absolute fullest" (neo)vim experience because you don't get the buffers/panes like you do in nvim though.
ctrl-w s : will split horizontally ctrl-w v : will split vertically
Commands work, and I just tested buffers specifically. I can type :buffers and I see a list. I was able to get vscode to switch tabs with :b 209 (I don't normally inspect buffers this way, but it's integrated and it works).
You’ll never convince me, however, that Microsoft’s embrace, extend, extinguish partially proprietary editor that uses the same LSPs as any other LSP client should be used by anyone. I wouldn’t touch it with a 100 foot pole.
There are turn key solutions for both Emac, Vim, and Neovim. They can all talk to LSPs, have DAP clients, fuzzy finders, file tree explorers, project managers, remote editing (terminal editors are by nature the ultimate remote editors).
Why isn’t he world would you put neovim inside of VSCode when you could just use neovim directly via GUI or terminal.
Besides showing the git signs in the gutter, it can do staging, diffing, navigation between hunks, line blame, can show deleted lines etc. If you have more advanced workflows, it might not be enough though. I use lazygit quite often as well.
If I am just living in the terminal, I like to use a mix of https://github.com/extrawurst/gitui (doesn't support signed commits yet!) and https://github.com/Wilfred/difftastic which provides amazing semantic diffs.
DiffView is good but there's no point denying GUI diff viewers are better than text ones, so I use one (meld or sublime-merge), which does mean launching a separate tool. That's fine for my limited uses (quick visual overviews, or fixing merge conflicts).
https://meldmerge.org/
the vimcast videos about it can be life changing.