> The main difference is that it chose javascript instead of lisp as its universal language, That is not the main difference. The main difference is that Emacs

> The main difference is that it chose javascript instead of lisp as its universal language, That is not the main difference. The main difference is that Emacs can be extended on the fly. While VS follows the traditional plugin approach. For VSCode to the have the same kind of extensibility it would have to allow opening an inspector on the _running_ instance. Click an element, jump to its source edit the source on the fly and have that change persisted. Or allowing your settings to patch (which by the nature of ES6 modules is not something you will be able to do). The on the fly extension is crucial for quick QoL improvements to your workflow. You can spend 5 minutes writing a function instead of having to setup a project/plugin to something as trivial as say, copying a .env file and updating some values when you create a [git] worktree. > Which is exactly the reason why... VSCode is winning the editors war. The main reason why VSCode is 'winning' the 'editor' wars is because Microsoft is spending tons of money to build a great product. Emacs, vim, and other open source projects can't compete as they don't have nearly the same amount of resources. They have healthy communities and are thriving FLOSS communities but people who are scratching an itch won't be writing monthly tours of new features like https://code.visualstudio.com/updates/v1_52 https://code.visualstudio.com/updates/v1_52 f/e. > ask anyone who had to maintain bash/awk/perl labyrinthine assemblies... Text in Emacs is richer than plain-text. You have overlays to annotate it with metadata, text properties, you can attach callbacks to it, etc. It is only at the boundaries that you have to resort to plain-text for interoperability purposes. This means it is easy to inter-op with CLI utils but present a richer, more powerful interface. Ej. dired uses ls.