Emacs is More Like a Terminal Than an Editor

#emacs #editors #ide #lisp

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-editor¹. 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 IDE². 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 plunge³ 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 mindset⁴. Additionally, I'd gotten bitten by a bug⁵. 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 pick⁶.

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 R E P L. 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 different⁷, whereas Emacs provides a uniform interface over lower-level tools⁸. 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 provide⁹. And more importantly, it's a way of empowering users through what is ultimately still a thin, but infinitely moldable layer of indirection.

Based on the advice I found in the wonderful book The Pragmatic Programmer. ↩
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. ↩
Using Clojure on a few projects in my work and digging into SICP and the Little Schemer series. ↩
For more on that read The Rise of Worse is Better and Worse is Better. ↩
I'm sure I can thank Bret Victor for this. ↩
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. Though that is at least in part about gaining an intuition for the state-of-the-art in programmer tooling. ↩
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. ↩
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. ↩
Although VS Code does now provide similar functionality. ↩