The key point of Emacs

Lately, I’ve been reflecting on why I’ve settled with Emacs of all other text editors. You may remember my old post where I go into lots of different code editors, and I list Emacs among them too. That post itself was written in Emacs, like everything else in this blog, but I can’t say that I understood the main point of Emacs back then. Err, I don’t think I do now, hence the post doesn’t use “main point” in the name, but it feels that I’m getting closer.

Each editor has its own philosophy that kinda sells it to you. Like, Vim’s keyboard-oriented editing language, where you execute actions on text objects or Kakoune’s similar but inverted model of selecting objects first, then operating on them, or even on multiple objects at once. Visual Studio Code has out-of-the-boxiness and user-friendliness paired with a rich amount of extensions, modern and beautiful interface with rich rendering capabilities. Sublime Text’s speed, and so on.

But what’s the philosophy of Emacs? Emacs doesn’t have an editing language like Vim¹, it’s not as user-friendly as VSCode or Atom, its interface is far from modern, and rendering capabilities are kinda limited. One might say it’s extensibility, but I don’t think it’s a proper term here. VSCode, Sublime Text, and Vim can be extended with new features as well. Another point I often hear is that you can make Emacs “your own”. Well, so can be done with Vim, and people go to great lengths to do it with VSCode or Sublime.

I think the key point is that Emacs isn’t really just an editor - it’s a platform. It doesn’t really matter what extension language Emacs uses, and it doesn’t really matter if Emacs has millions of packages, as all other editors do. What does matter is that Emacs is a platform that allows its users not only to extend it with new features, but also change how it operates at runtime. Emacs Lisp is great for that purpose because it was basically developed as a system-level language for the Emacs system. All of the system’s functions are available to you as a user, and you can do whatever you want with them, down to the core. And while its core is written in C, nothing prevents you from calling these C functions from Emacs Lisp, much like you can do from the system language of your operating system.

I think that’s what differentiates Emacs from most other software I use, and I think it’s a great model. It kinda makes me think about Emacs as a Smalltalk system, which isn’t just a language, but an image that you can operate on. And it matches how Emacs Lisp is tied to Emacs itself, and I don’t really think it is really worth decoupling one from another because Emacs Lisp isn’t the greatest Lisp out there, to be honest.

Sadly, unlike Smalltalk, Emacs’ GUI system is far less advanced. You take Pharo or Squeak, and it comes with a graphical interface with proper buttons, widgets, and so on. Then you look at things like GToolkit, which is based on Pharo, and begin to question yourself, why can’t we have something like this in Emacs? All these custom inspectors as they call them in GToolkit allowing you to interact with graphs, images, and even data structures are really nice to have².

There’s also another technology that acts similarly, although I can’t say it has the same level of integration with its core as Emacs or Smalltalk do. I’m talking about Electron, the technology behind Atom, VSCode, and a lot of other software. I hope you can see why I think it is somewhat similar to Emacs - as it is a dynamic runtime system that runs on a pretty advanced core, but in this case, the core isn’t just a virtual machine, it’s a full-blown browser (though it is stripped down, a bit). Browser’s rendering capabilities are impressive, and support for all kinds of formats is also great, which makes it a nice target to base user applications on. Though, it’s more limited than Emacs, because you basically only have the Electron API, and you can’t go lower (correct me if I’m wrong). And because of this limitation, I can’t think of VSCode as I think of Emacs, though Atom was so close to it, as their approach to the whole structure of the program was a lot more modular.

Speaking of GUI, Emacs is limited to text buffers and basic overlays. Sure, that can make it look like Emacs has some kind of widgets, but it doesn’t feel like interacting with a widget, as you still insert text into the text buffer basically. Some projects even incorporate SVG rendering to make Emacs look more modern, I tried this too, but it still feels not as a real GUI app. Developing a set of GUI widgets is a hard task, and interfaces came a really long way since Emacs’ inception, and things like Smalltalk were basically aimed at graphical interfaces from the start so the comparison isn’t really fair. Though, a lot of people argue that a proper GUI will make it hard to use Emacs from the terminal, to which I would say that it’s fair, but also why? And a lot will argue that Emacs’ text-oriented interface is better because it allows using the same set of functions for both text manipulation and interface manipulation (because it’s the same thing). I don’t think it’s a good design though, as it is basically re-purposing text editing features into a rendering engine which, while works, still makes me think that it would be nice to see a proper GUI implemented in Emacs.

Despite all of that, people basically live in Emacs. I do as well. I read and write mail, work on this blog, chat in IRC, working with Git, browse remote servers, read books, do planning, browse RSS feeds, and do lots of other minute tasks that I can’t really remember right now. All without opening a terminal, because with Emacs I don’t need one. What I’m trying to say here is that I don’t really need Emacs to be compatible with terminals, because, as I said, you can open Emacs SSH from it, you don’t really need to be able to SSH somewhere and open Emacs there, as a lot of people do with Vim. So a proper GUI won’t hurt Emacs in my opinion, because there’s no reason to run Emacs in the terminal at all.

And the thing is, I believe it is possible to implement a proper GUI in Emacs because, unlike in many other software, you can extend Emacs down to the core. And that’s why I love it, and I actually use it, changing the behavior of built-in packages to suit my needs, and creating helper functions to enhance the overall experience. For now, I can’t see myself leaving this ecosystem for something else, and Emacs is rapidly evolving, I think in the last three years there were more new exciting features than in the last five years before it. Maybe a proper GUI system will come as well, who knows? Or maybe a new rival appears, that realized what makes Emacs great, but also realized that there are still a lot of things to improve on in this model.

Anyway, I’ve drifted from the main topic of this post. The thing is, it’s not just about extensibility or ability to make Emacs your own - a lot of software can do that. It’s about being a platform that gives you all the tools you need to build upon. Which Emacs really excels at, in my opinion. Thanks for reading.