If you use Neovim, can you share why you chose it over VS Code
Every time I try VS Code, I get frustrated within 10 minutes and close it.
It’s a resource hog and the UI is kinda all over the place. The Vim plugin isn’t bad, but it only goes so far with the basic motions. It’s fine for basic editing but when you need to go deeper, it can’t go there.
I haven’t tried embedding Neovim yet, but that seems to be kinda of a hack. Besides I already have Neovim, so why would I embed it into a lesser editor?
But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed
I already have a Vim configuration I’ve been using for many years, so it was no big deal using it with Neovim.
I would also push back on the so-called fragility. I’ve been using Neovim for a 2-3 years and it hasn’t crashed once and I’ve done a lot of experimenting. In fact, I’m pretty impressed how well the many different plugins all work together. For example, I use the Tokyo Night colorscheme and it supports a bunch of the standard and 3rd party plugins by default:
In a way, it’s not new—lots of old-school Vim plugins I’ve used also work great with the rest of the plugin ecosystem.
Vim was designed from the start to be part of a rich development environment. An IDE typically is a monolithic application; Vim and Neovim are designed to work as the centerpiece of a system of applications used by developers where they can use the best in class utilities as extensions to Neovim.
Vim works with linters, compilers, extensions, command line utilities and has done so for decades--and that was before Treesitter, LSPs and being able to be embedded.
Every time I try VS Code, I get frustrated within 10 minutes and close it.
It’s a resource hog and the UI is kinda all over the place. The Vim plugin isn’t bad, but it only goes so far with the basic motions. It’s fine for basic editing but when you need to go deeper, it can’t go there.
I haven’t tried embedding Neovim yet, but that seems to be kinda of a hack. Besides I already have Neovim, so why would I embed it into a lesser editor?
But it still feels like a huge amount of work, hoop jumping, and _fragility_ just to reach parity with VS Code/Helix/Zed
I already have a Vim configuration I’ve been using for many years, so it was no big deal using it with Neovim.
I would also push back on the so-called fragility. I’ve been using Neovim for a 2-3 years and it hasn’t crashed once and I’ve done a lot of experimenting. In fact, I’m pretty impressed how well the many different plugins all work together. For example, I use the Tokyo Night colorscheme and it supports a bunch of the standard and 3rd party plugins by default:
* TreeSitter * LSP Diagnostics * LSP Trouble * LSP Saga * Git Signs * Git Gutter * Telescope * NvimTree * WhichKey * Indent Blankline * Dashboard * BufferLine * Lualine * Lightline * Neogit * vim-sneak * Fern * Barbar * Scrollbar * Mini
In a way, it’s not new—lots of old-school Vim plugins I’ve used also work great with the rest of the plugin ecosystem.
Vim was designed from the start to be part of a rich development environment. An IDE typically is a monolithic application; Vim and Neovim are designed to work as the centerpiece of a system of applications used by developers where they can use the best in class utilities as extensions to Neovim.
Vim works with linters, compilers, extensions, command line utilities and has done so for decades--and that was before Treesitter, LSPs and being able to be embedded.