Sorry for misunderstanding. I see now that you meant autocompletion like LSP (rather than M-x minibuffer completion). Emacs could benefit from built-in LSP, I agree.
Emacs-devel are keen for it, and eglot.el is a good contender for inclusion.
It's a great strength that NeoVim supports many languages, and VS Code uses Javascript.
Lisp is not widely used, and this is an impediment to Emacs' popularity.
However, when people speak about Emacs customizability, they are referring to a deeper level of customizability than most programs (even NeoVim/VS Code), in which its innards and UI are all subject to modification, at runtime, within the beast itself. This isn't necessarily a good thing, but it happens to be my preference at least.
> Emacs should have been what VSCode is now - a powerhouse of customizability that offers unmatched functionality by default.
+1.
Emacs is a powerhouse of customizability, and it needs to work on functionality by default.
> Instead it's a toy for some old people who are still holding onto the remnants of an age that passed a long time ago. Emacs is basically useless compared to VS Code, and its authors are what's holding it back.
I don't think Emacs is held back by its authors. The article might not make it clear but RMS does not contribute much to the vision or code of Emacs today. Read emacs-devel, and though there's occasionally some conflicts, the authors are keen on progress aligned with what people expect from an editor.
Emacs is a complex platform, owing to its unique vision on blurring the line between user and developer. The authors do a great job of keeping that up-to-date.
I have never used live export, but looked for it in its dropdown menu, found it, and clicked it: https://i.imgur.com/0LG6nnS.png
It renders images and doesn't rely on ASCII for its rendering.
I agree Emacs could benefit from some polish, on the whole.