I could ask the opposite: why do people choose terminal vim when you can easily add nvim integration to editors like VSCode and get 98-100% of what vim gives you along with much easier configuration of all those extras you mention like autocomplete, hover reference, refactor, etc.?
That's a bit of an overstatement, because I really do love vim/nvim and nvim integration isn't that good, but the fact is that adding a feature in nvim still means researching and configuring it where in something like VSCode you open a new filetype, it asks "do you want support for this file", click yes and you're ready to go. I can spend a few days trying to get vim to work in the way I want it for a specific filetype/framework, or I can get 90% of what I want from VSCode in 30 seconds and still have vim navigation and command support.
I find Coc.nvim plugins for neovim are virtually just as easy to set up as VS code plugins, VS code is a power hog and performs worse, and the vim bindings are rough around the edges with macros in particular. VS Code with a vim plugin is not a bad experience, but neovim+coc.nvim is just much snappier.
That may be, but this is the first time I've heard of coc.nvim and I've used neovim for years. So I'll bookmark this and at some point I'll look into it and do some research and figure out how to configure it and compare it to competitors, but is all that really worth the very slight performance advantages we're talking about? I can't type 1000wpm after all.
Sure, VSCode is a power hog and it's slow, but I make pretty good money so the cost of a more powerful development machine is trivial compared to the opportunity cost of doing all that research. Some years I really enjoy learning all about new ways to configure vim/nvim, but I recognize that it's really not an efficient use of my time, it's just been something I do more for fun.
Yeah I agree about it being something that's done because you enjoy it. Talking about what's an efficient use of time is so strange to me though, not to single you out in particular. It's like we're pretending our lives are so hyper-optimized that everything is a delicate trade-off. I spend a few hours here and there messing around with my setup because I want it to feel nice to use. It's not like I traded a couple hours of productive programming time for that. Sometimes I spend a few hours watching a movie.
For me a snappy editor experience, and vim in general, is about comfort, not optimizing for some theoretical top editing speed. I don't think I'd be a drastically worse programmer if I were forced to use windows notepad to edit code, I would just be more uncomfortable all the time.
The 100% full reason for me was that I had a job where I needed to SSH into our prod server about once per month and tweak some files. I was so terrified every time I had to do it because I was afraid of vim and/or nano in those situations. So I decided to get competent so I trusted myself not to make huge mistakes.
After about a week of using vim it clicked and I knew I couldn't go back to Sublime Text.
As for VS Code, I do everything I can to keep Microsoft products out of my life.
> The 100% full reason for me was that I had a job where I needed to SSH into our prod server
Statements like this are common, but they confuse two usages: (a) learning vi/vim well enough in order to use it in any unix environment vs. (b) using vim with a complete plugin/config suite as a primary development IDE replacement tool.
The former is IMHO an essential unix skill, but it's incredibly inefficient to try to use core out-of-the-box zero-plugin vim as a primary development tool. But once you start configuring an efficient dev environment, the GUI editors start to really outshine vim, and they still provide core vim functionality via plugins if you want it.
That's a totally fair point, and I realize my comment wasn't really in the spirit of that original thread in the first place.
What I really meant to convey is that I dipped my toes in just enough to get familiar, and that was enough for me to get fully hooked on vim. I've spent lots of time trying to make Jetbrains/IdeaVim and VSCode/vim-plugin work for how I write code. Significantly more than I want to admit publicly...but I come back to the boring old terminal every time.
I am not trying to convince any person on this planet that they should use vim. In fact, when other developers at work ask me if they should try I say "No" 100% of the time. But Jetbrains/VSCode are a firm step down for my workflow.
You can use Sublime Text remotely though, just requires some effort to set up.
My issue with Vim is remote servers and containers never have my (awesome) config.
It still pays off to know some basic Vim keybinds. You can often use them in other applications and every once in a while some machine only has vi. That said I grew up with DOS, do ctrl keybinds feel natural to me. Its just nigh annoying switching from macOS to Linux given the position of ctrl/fn/alt/super are different.
vscode is open source, there are forks(vscodium) where all the microsoft stuff is removed and you can audit it yourself if you think its sending tracking data back
I used this combo for a while, but there was a period of time where VSCode updates would break the vim integration. This was a few years ago, and I’ve recently reinstalled VSCode for use with F#, since Ionide seems to work better than in Neovim.
That's a bit of an overstatement, because I really do love vim/nvim and nvim integration isn't that good, but the fact is that adding a feature in nvim still means researching and configuring it where in something like VSCode you open a new filetype, it asks "do you want support for this file", click yes and you're ready to go. I can spend a few days trying to get vim to work in the way I want it for a specific filetype/framework, or I can get 90% of what I want from VSCode in 30 seconds and still have vim navigation and command support.