Emacs is More Like a Terminal Than an Editor
Tags: emacs, editors, ide, lisp
Published: 2023-11-23 17:16:48

---
layout: blog
title: Emacs is More Like a Terminal Than an Editor
category: Tooling
tags:
  - Emacs
  - Editors
  - IDE
  - Lisp
canonical_url: https://delonnewman.name/articles/2023/11/21/emacs-is-more-like-a-terminal-than-an-editor/
---
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[^1]. 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](https://blog.sanctum.geek.nz/unix-as-ide-introduction/)[^2]. 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[^3] 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&mdash;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[^4]. Additionally, I'd gotten bitten by a bug[^5]. 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[^6].

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](https://orgmode.org), [Magit](https://magit.vc), [TRAMP](https://www.gnu.org/software/emacs/manual/html_node/tramp/Quick-Start-Guide.html), or a [R](https://www.gnu.org/software/emacs/manual/html_node/emacs/Lisp-Interaction.html)[E](https://github.com/nonsequitur/inf-ruby)[P](https://cider.mx)[L](https://metacpan.org/pod/Sepia). But it wasn't until reading *[You Don't Need a Terminal](https://andreyor.st/posts/2023-10-27-you-dont-need-a-terminal-emulator/)* by [Andrey Listopadov](https://andreyor.st/about/) 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[^7], whereas Emacs provides a uniform interface over lower-level tools[^8].  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[^9]. 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](https://pragprog.com/titles/tpp20/the-pragmatic-programmer-20th-anniversary-edition/).
[^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](https://mitpress.mit.edu/9780262510875/structure-and-interpretation-of-computer-programs/) and the [Little Schemer](https://mitpress.mit.edu/9780262560993/the-little-schemer/) series.
[^4]: For more on that read [The Rise of Worse is Better](https://www.dreamsongs.com/RiseOfWorseIsBetter.html) and [Worse is Better](https://www.dreamsongs.com/WorseIsBetter.html).
[^5]: I'm sure I can thank [Bret Victor](http://worrydream.com/#!/LearnableProgramming) 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. Though that is at least in part about gaining an intuition for the state-of-the-art in programmer tooling.
[^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.