Is VS Code The Spiritual Successor To Emacs?

Vivek Haldar is a Python fan and considers Guido von Rossum “one of the best language designers of our time.” He was surprised, therefore, when von Rossum suggested in a Lex Fridman podcast that VS Code was the spiritual successor to Emacs. For many of us, that’s like lighting a stick of dynamite under our chair but Haldar considers the idea of VS Code being the spiritual successor to Emacs calmly and rationally.

Not surprisingly he disagrees. Von Rossum bases his assertion on the fact that VS Code and Emacs are both structured as an interpretive language engine at the core and the majority of the editor implemented in that language. In Emacs’ case, that language is Lisp. In VS Code’s case it’s JavaScript. Theoretically, that makes them both highly extensible but there’s a difference.

Haldar says that Emacs has two things that VS Code doesn’t:

Barrier-less extension

The idea that you can write some Elisp anywhere in Emacs, mark it, execute it with Meta+x eval-region, and have the effects take place immediately. If you like the changes you can add the code to your init.el and have its action take place every time you start Emacs.

Everything is a buffer

I’ve written about this before. As Haldar says, it basically means that whatever you do in Emacs, it’s in a buffer and subject to the usual Emacs editing and manipulation functionality.

I’d add a third Emacs advantage: Emacs is Free Software and not owned by anyone. I say that not as a true believing ideologue but as someone who’s been around long enough to know how Microsoft operates and to not trust them or their intentions. I worry that Microsoft will eventually revert to type and pull the rug out from under VS Code users.

In any event, Haldar reaches the same conclusion that I do: VS Code is not the spiritual successor the Emacs.