1) VSCode is very UI heavy and doesn’t allow consistent keyboard and text navigation. I want my text editor to be text-based, and it slows me down to have different types of windows (some of which seem impossible to hide permanently) with inconsistent forms of navigation.
2) The terminal window is its own thing, even if you open it in an editor window, which is then ignored by anything that interacts with the terminal. This is more what I want but is very limited and immature:
https://marketplace.visualstudio.com/items?itemName=jeffgran...
The lack of an infrastructure like Emacs comint mode also means there’s no good text-based database mode either. I want the same navigation, search and editing functions in every single window I have to interact with.
3) Where analogues to Emacs modes exist, they are universally less featureful, often because of fundamental limitations of the VSCode extension API. REPLs do less and offer less programmability. Edamagit is a fine and welcome effort but not as good as Magit.
If people want an editor with a little bit of auto completion and some squiggly lines to tell them they’ve typed something wrong VSCode is great. I have many mostly happy VSCode users within my organisation. But I think every individual programmer, like every team, should have a regular little retrospectives with themselves. What work did I do today, what would have made it flow better? In every case, I can build that in Emacs, but it’s much more friction in VSCode. This is partly immaturity and partly the APIs not offering as much. Long term I’m rooting for VSCode because it’s snappy and has undeniable market share. But it’s never quite been there for me yet.
Then again, I might pre-date the which editor to use and how to configure it era.
My point is you could configure all this stuff in Vim or Emacs but it's not as straightforward plus it wastes time when onboarding. We'd rather have an IDE like experience.
The only time I ever had to use vscode working with other programmers was for pair programming, using the vscode sharing thing. Apart for that, not being able to use emacs would be a deal breaker - using other editors is like wading through quicksand for me.
It's not just the code, we'd want everyone on the team to use the appropriate toolsets including debugging and error checking support. They can set it up in Vim and Emacs if they want but it saves time for the team as a whole if we all use a standardized set of tools.
It takes weeks (at least) using emacs/vim until text editing/movement starts to pay off. There's no learning curve for `M-x package-install`, but if there is some variable that needs to be customized, like the path to an executable or something, that's a whole rabbit hole to go down, and at some point you need to learn lisp or you'll waste a lot of time being confused by errors.
During the only programming course I took in college, one in which emacs was required, I spent as much time learning emacs as anything else (it was also the most valuable thing I learned so I'm grateful in the long run).
Completely agree: the entire company should be on a common, future-proof, extensible, free platform: Emacs!
I honestly don’t understand why anyone bothers wasting effort on any other editor.