VSCode-Neovim: Use embedded Neovim in VSCode without emulation
github.com
github.com
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.
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...
Ctrl+`
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.
With neovim you just get that by default. Everything is thought around that.
> 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'll keep an eye on this thread for a day or two and try to add more essential hotkeys if I think of them.
For every plug-in I’ve installed in vim, I used about 5% of their behavior. I’ve spent time looking through plug-in utilities and thought “oh that’s useful” and then forgotten about them by the next day. I’m aware that in vim, I can type :substring<tab> and get a list of commands. As far as I recall, I only get name matches. VSCode’s action search massively improves the user experience of this, allowing me to scan descriptions of plug-in commands.
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.
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.
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.
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).
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’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.
the vimcast videos about it can be life changing.
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).
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.
Vim is my go-to text editor and VS Code with vim emulation is my go-to IDE, so I was excited to try.
The vim emulator puts the `:` command in the status bar on the lower left, quite like vim itself does. Type `:w` and you see that in the status bar.
By contrast,the way that command `:` is handled in the embedded neovim extension is that a search window pops up at the top where the commands and files drop-downs are (same place that gets the cursor when hitting ctrl-p). This confused and dismayed me so much that I immediately noped out, disabled the extension and went back to using the emulator. It might also have been dismaying that `w` was not one of the listed commands, only `wq` which is not what I wanted. `w` did work, but I was done.
I probably could get used to it, but I'm inclined to jettison things that mess with what I'm used to unless there's a massive value-add. As for now, I pretty much only use vanilla vim and so the emulator is good enough. When I need more power, I open vim either in a separate terminal or sometimes right in the VS Code embedded terminal. I don't really have an intense need for real neovim in VS Code at this point.
Finally, I do want to give props to the creator! This is an amazing accomplishment, and I hope that my feedback is not discouraging! If there could be a setting to reflect the commands in the status bar as the vim emulator does, I will be eager to try it out again. But still, great job!
For something like editing text, as a programmer you do this endlessly - it is absolutely worth it to be ruthlessly efficient at this, even if you have to pay effort learning it.
But for, say, installing a plugin in your text editor... that's something you do a handful of times a month. The mouse is much more adaptable and easy to use, even if you give up accuracy.
This way, you can be efficient at editing text without having to learn keybindings for a bunch of misc things that you do rarely.
I'm not disagreeing with this comment all, just throwing my anecdata at the somewhat squishy "longer" word in that sentence.
For me, I went cold-turkey with vim (my employer wanted me coding on both Mac and Windows at more or less simultaneously; I figured it would be a useful investment of time to learn a single set of hotkeys that I could use on both systems and get into my muscle memory, rather than trying to keep Xcode hotkeys and Visual Studio hotkeys straight in my head)
I stopped using literally any other text editor or IDE either at work or at home, just to try to learn vim as fast as possible, and spent a bunch of recreational time playing VimGolf.
As I'd expected, it was catastrophic for my productivity initially, but I reached a basic proficiency within five days; I got back to my normal development cadence quickly enough that my lead didn't even notice I had taken time to teach myself to use a "difficult" text editor; I just had one week where I was slightly behind schedule, before catching back up and getting ahead during the following week, where my skills improved even further.
It definitely is a longer learning curve before you can say that you've "mastered" vim than most other editors. But you can reach a basic competence equivalent to other (non-emacs) text editors pretty quickly; it's just that there's still a lot more useful functionality you can learn after that point.
I forget all of the settings I changed to make it work for me, but it's mostly usable as a vim replacement now.
I needed to set 'use control keys' or something like that, so I can use Ctrl-[ instead of ESC to enter command mode, something I've done since Vim 2.0 days (and before that in Elvis).
I also override vim bindings for Ctrl-X, Ctrl-C, Ctrl-V, (cut/copy/paste), Ctrl-Z, Ctrl-Y (undo/redo) so I can use vscode for that behavior instead. I'll also use the normal vim commands for those also (like yy, p, etc). Best of both worlds I suppose.
My only gripe with this approach is undo/redo stacks can sometimes get lost between vim and vscode handling it. There is a similar extension for Visual Studio which has never lost the undo/redo stack like the vscode extension does.
Is any of this any better with the newest vscode-neovim? I tried vscode-neovim a while back and had go back to vscodevim after having problems.
Just use NeoVim. Name one reason why you need VSCode.
AstroNvim comes to mind https://github.com/AstroNvim/AstroNvim
Plenty of reasons
No need to configure anything.
Company policies. ("we all use the same editor")
1. it's just nice to see your selection before u do any action.
2. There's not benefit to the new model, either you like it more or like it less, why does everything have to give a benefit? Maybe it's just about the preference.
3. Helix requires less than 50 Lines of TOML to configure, to me this is well worth it, as with neovim, i easily needed like ... 300 Lines of Lua code? Something like this.
I was a big vim user back before VSCode, so I’m happy being back in my obscure editor hole.
> command mode has primacy; insert mode is a time-bounded special case
with:
> insert mode is every other mundane editor; use the Esc key to enter the matrix (i.e. command mode)
I think you mean normal mode.
Back then, I used a custom homebrew tap to get the proper Neovim version installed, and the plugin mostly worked. Occasionally the editing context would get messed up, and still does. I've found that changing tabs inside VSCode resets the neovim context, and that's a nearly-instant fix for most issues I see now.
It also works with the default version of Neovim from homebrew. No more custom tap needed.
I personally started using Vim bindings in VSCode recently due to wrist pain issues and have been geeking about it a bit. Though there is still a fair bit of cognitive overhead for basic editing operations that were second nature previously.
sure it doesn't have :map or other commands but as far editing and moving around it work well for me....
as far vscode-neovim i have tried that but it was freezing too often for me (on osx and linux) I would have to restart the plugin extension host or something to get it fixed.... much nicer to have configuration in a .vim file tho compared to json based configuration of vscode-vim
I actually enjoy more idea emulation of vim which I think is much more advanced.... but vscode is a good middleground between an editor and ide or at least for my debugging sessions.
VSCode's multiple cursors is generally more powerful than Vim's nasty small imperative commands you have to glue together to try to get efficient editing.
I've only got one config file for neovim that still works for vim, so your info on that is just plain wrong.
What defaults did you have difficulty with? All my settings were mostly the same.
Same.
Neovim just enables most of the settings almost all Vim users turn on anyway; it’s not a dramatic change by any means.
Here is a detailed list of all the differences on the NeoVIM docs: https://neovim.io/doc/user/vim_diff.html
It's totally fine if you simply prefer VIM, of course.