VSCode-Neovim: Use embedded Neovim in VSCode without emulation(github.com)
github.com
VSCode-Neovim: Use embedded Neovim in VSCode without emulation
https://github.com/vscode-neovim/vscode-neovim
111 comments
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
> 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
Thank you for posting these!
My pleasure! This plugin is hands down my favorite VSCode plugin. I worked mostly in vim before, and this plugin made me comfortable doing project work in VSCode.
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.
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.
All that `cmd`ing makes me feel like I'm in Emacs ;). I wonder if there's a way to bind those actions to vim-like keybindings.
cmd-p is an absolute must if you use this plugin. Thanks for sharing!
I’ll add onto this, cmd-shift-p is the reason to use VS Code over neovim/vim.
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.
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.
Personally I use Telescope, which has a commands menu you can use to fuzzy find through all known commands similar to shift-p. That being said, I've removed almost all of my neovim plugins. stock vim/neovim is surprisingly capable
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.
But the actual editing doesn't use the mouse.
But the actual editing doesn't use the mouse.
If you have the proper jump to definition set up, vscode-neovim actually has a keybinding (that matches vim/neovim)
gd (go to definition)
You'll also like
gh (peek definition)
gd (go to definition)
You'll also like
gh (peek definition)
>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...
Sounds like a minor annoyance at best... Where vim-mode is important to me is editing and navigating code, not when installing plugins...
As I said, it's one example. Anything outside the code window suffers from the same problem, not just installing plugins...
I didn’t expect to disagree with you at first because I also struggle with vim
-Code plug-ins, but it really never occurred to me that it would cover the entire functionality of Vim outside the editor and file navigation.
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
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.
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's worth pointing out that while Vim/Neovim can be fully used without a mouse you can still use one if you want to.
That includes mouse wheel, clicking tabs, resizing windows, balloon help amongst others.
That works over SSH too.
That includes mouse wheel, clicking tabs, resizing windows, balloon help amongst others.
That works over SSH too.
VspaceCode might help you and others: https://vspacecode.github.io/.
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
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
>>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.
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.
With neovim you just get that by default. Everything is thought around that.
In what scenarios were you reaching for your mouse within emacs?
Seems like they meant using vim bindings everywhere requires much work to configure.
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.
https://onivim.io/
https://onivim.io/
Onivim development has stopped, it is now abandonware: https://github.com/onivim/oni2/issues/3811#issuecomment-9103...
Woah, that really sucks. I checked their website some time ago and though they still had momentum.. :( Hope that rewrite people are talking about in the issue replies does happen at some point.
SpaceVim is also a fine contender with its LSP support: https://spacevim.org/
Onivim is no longer being developed :(
If only there was some sane oob setup for neovim with decent file exploring, and debugging.
Not sure if you know, but you can install plugins from terminal.
Exactly this!
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.
See "Affinity" docs here for putting it in its own thread: https://github.com/vscode-neovim/vscode-neovim#installation
See "Affinity" docs here for putting it in its own thread: https://github.com/vscode-neovim/vscode-neovim#installation
This must be a new option, hadn't seen it before. Thanks!
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…
Oh snap!
Been more and more annoyed lately about just this. Thank you for sharing!
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.
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
0: https://github.com/folke/which-key.nvim
0: https://github.com/folke/which-key.nvim
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 :)
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.
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.
yep, that's why I want it
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.
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.
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.
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.
Been using it for a couple of years. No problems.
You don't get the "absolute fullest" (neo)vim experience because you don't get the buffers/panes like you do in nvim though.
You don't get the "absolute fullest" (neo)vim experience because you don't get the buffers/panes like you do in nvim though.
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).
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.
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…)
Gitsigns was good enough for my workflows: https://github.com/lewis6991/gitsigns.nvim
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.
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.
https://github.com/TimUntersberger/neogit & DiffView if I want everything inside neovim.
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.
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-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).
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.
https://meldmerge.org/
https://meldmerge.org/
have you tried fugitive?
the vimcast videos about it can be life changing.
the vimcast videos about it can be life changing.
Have you tried Fugitive?
Ok, I tried this out. Setup is a bit of a chore but not difficult, mostly making sure that the correct version of neovim (> 8) is installed. I have only one bit of feedback, but for some reason it's a deal-killer for me.
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!
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!
I remember trying neovim with Atom a while ago. At that time I realized that me using nvim it's not just about motions/plugins/no mouse, etc, but rather the whole terminal experience. For example, I rely heavily on tmux for splitting my screen whichever way suits the current task best and then, I may spontaneously open nvim in some of the splits or run other CLI tools. This experience is not the same with the CLI built into vscode or any other IDE.
To me the greatness of using something like neovim/vim is that you don't have to use the mouse. This I don't know what's good for...
The advantage of Vim is efficiency and speed. The disadvantage is that it has a longer learning curve.
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.
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.
> The advantage of Vim is efficiency and speed. The disadvantage is that it has a longer learning curve.
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'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.
Good for people who like the ergonomics of VSCode (one-click plugin installs, everything simply "just works" out of the box) with the ergonomics of Vim (modal editing, speed).
This. I'll go to VSCode from Neovim kicking and screaming, but frankly VSCode + a good Vim plugin is the pragmatic choice for most people out there looking for a Vim-like editor.
I don't use this extension, but I have used the 'vscodevim' extension for many years now.
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.
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.
This seems like a lot of work to ultimately have a Frankenstein monster.
Just use NeoVim. Name one reason why you need VSCode.
Just use NeoVim. Name one reason why you need VSCode.
* If you want 50ms latency on every interaction with the editor
* If you want to send telemetry to Microsoft
* If you want slow fuzzy search for massive codebases
Plenty of reasons
Plenty of reasons
Best out of the box python experience out there.
No need to configure anything.
Company policies. ("we all use the same editor")
No need to configure anything.
Company policies. ("we all use the same editor")
Bonus: Neovim isn’t phoning home to Microsoft nor does it try to bifurcate communities on using proprietary plugins.
I don't have to spend a bunch of time configuring VSCode, I can simply do a one-click install for plugins, and I can focus on the editing interface with Neovim.
There are some outstanding out-of-the-box solutions for NeoVim.
AstroNvim comes to mind https://github.com/AstroNvim/AstroNvim
AstroNvim comes to mind https://github.com/AstroNvim/AstroNvim
I used to use this before I switched away from VSCode for greener pastures. It was far and away the best option for vim editing. It’s great because you can still make use of any neovim plugins you have without needing extra VSCode extensions.
What are your greener pastures?
helix is pretty nice if you’re willing to challenge your traditional vim editing model. vim is action -> selection. helix is selection -> action. Beyond that helix feels like a modern vim. LSP natively supported. DAP as well. Very little configuration and bootstrapping to wade through.
What does that shift in paradigm give you over Visual Mode in Vim?
My 2 cents to this as a helix user.
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.
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.
Switched to emacs via doom emacs about three years ago and haven’t looked back!
I was a big vim user back before VSCode, so I’m happy being back in my obscure editor hole.
I was a big vim user back before VSCode, so I’m happy being back in my obscure editor hole.
This has caused me to realize that I need to replace my old model of vi:
> 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)
> 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)
> Command mode
I think you mean normal mode.
I think you mean normal mode.
I tried this plugin a few years ago. It was neat but ultimately buggy and not ironed out enough to use daily. To people who currently use it, has it improved noticeably?
Yes, it has. I've used it for years as well, and I think I know the bugginess you're referring to. Some time back, it required Neovim 0.5.0 or 0.5.1, and that wasn't yet in the official Neovim homebrew package. This was actually documented on the vscode-neovim homepage, but it was easy to miss.
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.
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 think I actually built neovim from source when I was testing it out. Either 0.4 or 0.5, yeah. I think the lost context was frustrating IIRC and I didn't know that switching tabs fixed it. I just got frustrated and opened up real nvim when that happened.
Could be Baader–Meinhof phenomenon but I feel like Vim is having a resurgence due to lots of streamers and youtubers using it.
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.
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.
I think so. Also "in real life", in 20 years around coders, I only met 1 Vim user and 0 Emacs users. Everyone else has always been running the IDE for that language, or something like Notepad++...
While I'm missing global mode my choice would be vscodevim.vim (1), mainly because it supports VScode in-browser mode such as github.dev and gitpod.io
(1) https://open-vsx.org/vscode/item?itemName=vscodevim.vim
(1) https://open-vsx.org/vscode/item?itemName=vscodevim.vim
when I am not in Emacs+evil and I have to open vscode for launching the debugger I use vscodevim, I am not sure why people say it's too limited, it does the job more than allright for me and I tink I use vim keys and motion to its fullest....
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.
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.
Does that mean that I don't have to learn how to use VScode at all ?
I use the regular vim extension in VSCode. How does this compare to that?
Day and night. I haven't touched the regular vim extension in years, but its vim compatibility and feature set depends on the extension author. This plugin starts up neovim as a backend server and sends the file and keystrokes to that. It's not emulation, it's actually Neovim.
Also check out the VSpaceCode extension bundle - it reduces the need to use the mouse, but unfortunately not completely.
The Vim mode paradox: If you enjoy working in Vim mode in other editors, you probably aren't familiar enough with Vim functionality to justify your use of Vim. Not having q/ nor q? is already enough for me not to want to use this.
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.
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.
For when you hate Emacs so much, you need to form a Voltron of non-Emacs editors to fight it with.
I used VIM plugin until now, was happy to see this. However, tried installing it on top of neovim 0.9.0-beta and VS code complains that the version nees to be 0.5 or higher... switching between modes worked but moving (jkli) didn't. So gave up trying to install it. Might try later looks interesting
But can I embed VSCode on Neovim? Yeah, didn't think so.
That's pretty much what coc.nvim is
[deleted]
I reverted to Vim after trying NeoVim for a few weeks simply because a lot of Vim defaults had to be chased-down and configured just to get basic Vim features in NeoVim. NeoVim also requires messing with a ton of config files compared with Vim so no thanks.
Hmm, I used vim for nearly a decade then switched to neovim a few years ago and it was pretty much seamless.
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.
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.
Hmm, I used vim for nearly a decade then switched to neovim a few years ago and it was pretty much seamless.
Same.
Neovim just enables most of the settings almost all Vim users turn on anyway; it’s not a dramatic change by any means.
Same.
Neovim just enables most of the settings almost all Vim users turn on anyway; it’s not a dramatic change by any means.
Your single `.vimrc`-style config file should just work, NeoVIM just looks for it elsewhere. Most other differences are config defaults, the majority of which I suspect you have manually added to your current VIM config anyway.
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.
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.
Weird, I've had exactly the opposite experience. Neovim seems to have much more usable defaults IMO, I was able to decrease my config size a fair amount when I stopped trying to maintain a vim-compatible config file, in large part because of the settings that were already default in nvim.
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.