Emacs is More Like a Terminal Than an Editor

21 November 2023
Emacs Editors IDE Moldable-Environment Lisp Tools

Photo by Goran Ivos on Unsplash

I’ve long been a command-line nerd. It was, after all, my first computer interface starting with Apple II’s in school and DOS at home when my mother bought our first computer when I was 10. While I was fascinated by graphical interfaces when I first encountered them, text-based interfaces continued to hold a certain mystique especially as I became familiar with the UNIX shell through my early experiences with Linux based systems when I was in my teens.

As I continued to work at mastering the various skills of the programming trade, I decided to settle on a preferred text-editor1. At that point I settled on Vim for it’s ubiquity and extensibility. Over time I came to embrace the idea of using the UNIX environment as my primary IDE2. From that standpoint the UNIX shell and it’s various associated tools provide everything that you get from an IDE. I found that I was quite content with this as my default editing and programming environment with the exception of using IDEs for Java & C# when I used them.

When I finally took the Lisp plunge3 I started to wonder if I was missing something by not using Emacs. First, I’d never gotten into writing my own Vim extensions because Vim script—well let’s just say Vim script isn’t Lisp, and second I was coming to realize that there was something different and at least equally powerful about the Lisp vs. the UNIX mindset4. Additionally, I’d gotten bitten by a bug5. I wanted to understand the state-of-the-art in tooling for the sake of trying to get a sense of how we could do better, and the world of Lisp and Smalltalk seemed like some of the ripest fruit to pick6.

So now I’ve been exploring Emacs for a few years. Early on I had the “Emacs is a computing environment” or “operating system”, but definitely not an “editor” aha. As a result, I’ve found myself keeping an Emacs window open almost all the time to be ready for use whether I need a text editor, Org Mode, Magit, TRAMP, or a REPL. But it wasn’t until reading You Don’t Need a Terminal by Andrey Listopadov that the full impact of this hit me. After trying out his suggestions I hardly find myself opening a terminal at all whether it’s iTerm or vterm or the terminals integrated into RubyMine or VS Code.

Emacs is my terminal. Just as when I was primarily a Vim user I always had my terminal open and I would access my various tools from it. Now I always have Emacs an arm reach away. But there is a difference. And I think the difference speaks to the difference between the Lisp and the UNIX mindset. From a UNIX shell each of the tools are different7, whereas Emacs provides a uniform interface over lower-level tools8. For example, if I want to access a remote server (or docker container) I use the same commands that I use to open files locally, and once I do connect all the commands I normally use now work on the remote server as well. This is a way of taking your configuration with you that Vim simply doesn’t provide9. And more importantly, it’s a way of empowering users through what is ultimately still a thin, but infinitely moldable layer of indirection.

  1. Based on the advice I found in the wonderful book The Pragmatic Programmer

  2. I even tried my best to replicate this experience on Windows (with mixed success) since I often used Windows machines in my work at the time. 

  3. Using Clojure on a few projects in my work and digging into SICP and the Little Schemer series. 

  4. For more on that read The Rise of Worse is Better and Worse is Better

  5. I’m sure I can thank Bret Victor for this. 

  6. Having long been an IDE user of the C++, Java, and C# sort I’d always found them helpful, but ultimately disappointing. Though I have recently succumbed to using RubyMine and VS Code for my Ruby and JavaScript work, respectively. 

  7. UNIX command line arguments are infamously inconsistent, though we celebrate the openness of the system—that it’s disparate parts can be tied together with the very thin, but powerful abstraction that the shell provides. 

  8. Some of this uniformity is due to the way Emacs has been configured for me. Since I’m a Emacs newbie, I’ve resorted to using Doom Emacs, after initially trying to build my own configuration. But in the end, Emacs provides the uniform substrate that enables that experience. 

  9. Although VS Code does now provide similar functionality.