If you actually go through the crazy slog of making it usable and beautiful, then you pass the test and are hooked forever.
The same issue exists in Vim. So many nice features of Vim (such as file management using buffers) are underused, because by default they aren’t configured in a usable way.
For each their own I suppose. I despise those bindings and use the tab key instead, like nearly every other program that has completion.
I've been impressed that VSCode has managed to implement features Emacs has had for decades. One day it might catch up as long as MS keeps pumping millions into its development.
For me though it's still not even close.
Getting used to tramp, magit, and eshell has effectively made it so I will be in Emacs forever. Adding in developer modes helps. Same for org. But really it is the seamless eshell ability to "cd /ssh:mycomputer/" and not with about reconnecting a terminal over and over that is something I don't want to leave.
So, it is close. But most of Emacs "just works" over a tramp connection. From git to old and new code completion. And has done so for a long time.
Emacs' core strength is that you can shape Emacs to fit any need and workflows you may have. Secondly, you can also shape Emacs to have those workflows apply consistently across any domain you work with.
With VSCode it's always the opposite: You need to adapt to whatever VSCode supports, and each domain needs to be handled differently.
In my book, that will always make VSCode an inferior tool, even if what it does, it does indeed do excellently when considered in isolation.
I find it interesting that this statement is hard for me, a daily emacs user who has loosely followed and lightly tried VSCode, to assess.
VSCode's pair programming stuff looks like it could pull me over if I was on a team of people using it.
From a language integration standpoint I'm probably hitting the same lsp server the VSCode user is, probably getting the same red squiggles from the same compiler and linter. Emacs has always been competent enough at general text editing. I enjoy using the Emacs git client Magit.
It's not clear how to compare the amount of time I've spent configuring Emacs over the years to what I would have spent learning new environments if I had been swapping editors instead.
Also VSCode puts my poor laptop to its knees. Core i5 cannot handle few keystrokes in a row.. that was quite a shocker tbh.
But the moment the language-servers kick in and start analysing code and projects, the horror starts. It eats ram, cpu and grabs all attentions in can gain. Emacs can have those problems too, but there it's simpler to avoid those stuff. But to be fair, in VS Code to some degree you can deactivate it too it seems.
emacs is by now quite inferior to VSCode for most thing
I'm pretty familiar with both environments. Objectively there are things that VSCode does very well that emacs is weak at, though you can hack about and get some sort of approximation usually. And there are things that emacs does very well that VScode is weak or nonexistent at, though you may be able to hack an approximation together.
The problem with these discussions tends to be that people fall into camps where they consider other peoples must-have functionality to be irrelevant or unimportant, so "their" tool of choice "obviously" is "better".
This is especially true of something like VScode vs. emacs, where the natural domain of VScode is much narrower than the natural domain of emacs.
Emacs is for people who like to deeply personalize their editors. That's why I use it. But it takes time and learning elisp and many people are unwilling to do that.