> Its largest competitor, VSCode, Just Works most of the time! You load a file, it detects your intent, and it will install the necessary extensions _along with any additional system packages necessary_. Compare this to Emacs, where it's usually quite unclear what packages to use and what tools they need to operate. Eglot? lsp-mode? Which language major mode, and which language server? How do I get them to work with company mode and so forth?
If you actually think that what VSCode can do here is remotely equivalent to what Emacs can do after customization, then I suspect you don't really understand Emacs.
Yes, VSCode does an excellent job getting you to 80%-90% of where you want to be. But because of the lack of a deep extension language (or to be fair to Emacs, an extensible implementation language), VSCode will make it very hard to get to precisely where you want to be.
Maybe that's OK for a lot of people. But those of us who have used Emacs for quite some time are quite attached to that "final 10-20%", and you can keep your language servers and "detecting my intent" and just leave us be with the way we do things.
It's not even that - My problem is that I depend on emacs for the first 50% of my workflow, not the last 50%. For example, I use key chords for every common operation - ;h ;j k; l; move between panes, xz invokes M-x, kj brings up the buffer list, z\ and z- split panes, etc. I barely go ten seconds without using one of occur, change-inner, a 500-element kill ring, consult-yank-pop, tramp, magit, etc. Emacs works so well for me not because it has crazy extensions, but because its extensibility goes so deep that you can bring the crazy extensions deep into the tightest loops in your interaction with the editor where you can gain the greatest benefits.
If you're not a professional web developer, spending 80 hours learning how to modify Emacs will give you much more control over Emacs than the control you get from spending 80 hours learning how to modify VSCode.
Or ar least that was my experience though I was in my prime when I learned Emacs decades ago and almost 60 years old when I spent the 80 hours learning how to modify VSCode.
(I feel I have barely scratched the surface of VSCode and of web tech.)
Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.
One more thing. For years I went without internet access in my home, yet during those years I continued my habit of doing my emacs modifying at home: all I needed to do was make sure I had the Emacs Lisp reference manual and the Emacs Lisp source-code package installed. On every Linux distro I have used, these are standard packages, and they are all the information I needed to make most of the modifications I made to my local Emacs environment. In contrast, although there are troves of documentation on web tech, I have never succeeded in making a usable offline local copy of any of these troves, and wouldn't consider trying to modify (or explore the internals of) VSCode without constant access to the net.
> Web tech gives you a greater degree of control: e.g., Emacs Lisp cannot put red sqiggles under text like VSCode does, but rather limits the user interface essentially to one large "textarea" (though in contrast to TTY interfaces, Emacs has good support for the mouse), but it is very rare for me to want web tech's greater degree of control.
Emacs can certainly apply red squiggles and many other rich text formatting, through the use of faces (which is how all syntax highlighting is implemented). Emacs also has a rich text-properties API through which any part of a buffer's text may be propertized with metadata. And it also provides overlays, which "overlay" text, also optionally with additional properties, without modifying the buffer text itself.
Together, these features are used to implement GUIs such as the Customization system with widgets, buttons, clickable links, collapsible sections, etc., as well as red-squiggle-style linting tools like flymake, flycheck, and LSP-related tools.
If you actually think that what VSCode can do here is remotely equivalent to what Emacs can do after customization, then I suspect you don't really understand Emacs.
Yes, VSCode does an excellent job getting you to 80%-90% of where you want to be. But because of the lack of a deep extension language (or to be fair to Emacs, an extensible implementation language), VSCode will make it very hard to get to precisely where you want to be.
Maybe that's OK for a lot of people. But those of us who have used Emacs for quite some time are quite attached to that "final 10-20%", and you can keep your language servers and "detecting my intent" and just leave us be with the way we do things.