A spiritual successor to Emacs
I’ve been writing Python since version 1.5.2, and I think Guido von Rossum is one of the best language designers of our time, but I was a bit taken aback when on a recent Lex Fridman podcast he said, “To me, VS Code, in a sense, is a spiritual successor to Emacs.”
His rationale for that claim:
The key part of Emacs is that it’s mostly written in Lisp … There’s a core implementation that can read the file, put bits on the screen, and manage memory and buffers. Then, what makes it an editor full of features is all the lisp packages and, of course, the design of how the lisp packages interact with each other and with that base layer of the core immutable engine.
… almost everything in that core engine in Emacs’ case, can still be overridden or replaced. And so, VS Code has a similar architecture, where there is like a base engine … and it has a sort of a package manager and a whole series of interfaces for packages and an additional series of conventions for how packages should interact with the lower layers and with each other.
…. And so, the sort of extreme extensibility and the package ecosystem that you see in VS Code is a mirror of very similar architectural features in Emacs.
I agree that VS Code has a similar architecture to Emacs, in that it consists of a core language runtime, with most functionality built on top of that. For Emacs, that is Lisp. For Visual Code, JavaScript. But the Zen of Emacs (like the Zen of Python), is very, very different.
If I were to distill Emacs down to its two core ideas, they would be: barrier-less extension, and everything is a buffer.
Barrier-less extension: The way you change behavior in Emacs is by writing and evaluating Emacs Lisp expressions. You can do this anywhere in Emacs, which is to say, in any buffer in Emacs. Write elisp. Mark it. M-x eval-region. And now your editor is in a new universe. If you like that universe, you save that little elisp snippet in a designated place (init.el or something similar) so that you don’t lose it and Emacs evaluates it when it starts up again. This is ingrained into every longtime Emacs user. It is probably the second thing a newbie Emacser learns after the basic key bindings. This mode of changing the editor immediately by evaluating Lisp expressions is central to Emacs’ customizability and power.
Everything is a buffer: Emacs turns its full power towards fine-grained surgery on text. So why keep any part of it outside the reach of that power? The buffer as a central organizing concept is both simple and powerful. Every piece of text everywhere is in a buffer. It is subject to the same text manipulation. This includes shells and Dired.
When you combine the above two simple principles, you get nearly unbounded combinatorial power. Every shell interaction and its output becomes a text buffer. A directory listing in Dired can be edited (and then those changes persisted back!) just like a regular Emacs buffer. You can start climbing the levels of Emacs proficiency, a ladder that has no end. Because of this, Emacs can be the editor of a lifetime. You mold it to your usage over time. It becomes your tool forge.
VS Code lacks both of these ideas. But clearly, judging by its popularity and mindshare it has found success by doubling down on its strengths. It has just picked a different set of values than Emacs.
VS Code is a product from a giant tech company: Microsoft. One with a history of focus on developers, because they realized early how crucial developer mindshare was to maintaining the appeal of Windows. So VS Code has what Emacs doesn’t– product managers. People who create, articulate and then execute a strategy to capture a given market.
Emacs, by comparison, is the rag-tag Rebel Alliance. Maybe it also suffers from the Lisp Curse: Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp. That’s why instead of one canonical, well-maintained, bug-free implementation for a set of functionality (e.g. completion!!), it has twenty, with five of those actually solid and reliable enough for regular use, but with very differing philosphies and feature sets. Some might view that as a strength. Others may be turned off by it and turn to VS Code because It Just Works.
Speaking for myself, I’ve had to begrudgingly use VS Code once in a while simply because it is so prevalent and becoming the canonical editor (with all the tooling support that goes along with it) in more and more scenarios. But the paucity of its abstractions grates on me at every turn. The command pallette is a shadow of M-x in Emacs. There are no macros. The terminal doesn’t act like any text “buffer”. To “extend” it you have to write an extension, and there’s a ton of process and setup around it. You can’t just write JS expressions in a file and evaluate them to change the behavior of the editor. And on and on.
So no, I don’t think VS Code is the spiritual successor to Emacs.