Emacs Is a Lispboard

What would have happened if Emacs' default buffer had been a terminal emulator? Conceptually, from the outside, it would be perceived as a terminal on steroids with Lisp as its scripting language. Maybe we would be talking about iTerm2 vs Emacs, or Kitty vs Emacs, or even Bash vs Emacs. And what if the default buffer had been Dired, the file manager? History might have created rivalries such as Total Commander vs Emacs, or Finder vs Emacs.

But history took another path. We already know that if you launch an Emacs instance without any configuration whatsoever, what you see is a buffer with the following message:

A notepad with an embedded Lisp interpreter. Its natural rival is Vim with an embedded interpreter (Vimscript). However, the editor that made us all memorize :q! stayed in the buffer, while Emacs kept expanding with more and more software until it became an interface to the operating system.

I'm an Emacs enthusiast, and maybe that costs this article some credibility. However, I'm not here to tell you how fantastic the GNU editor is, nor to convince you to use it. My goal is to explain why the web browser is its true natural rival, and why Emacs is a Lispboard where you build the way you want to work.

To set the stage, let's do a little thought experiment.

Suppose I want to work in a single place for all my contexts, both personal and professional. That way I memorize my shortcuts, apply my configurations and never have to switch contexts. Everything lives under the same window.

It's a problem, because it means merging programs that have nothing to do with each other but need to collaborate. For example, a terminal emulator, an email client and a code editor (or IDE). With a layout system, inside the same window, I could have one column with my email inbox, another with the terminal and a third with my IDE ready to write whatever I need. In this space, it would be easy to write a bash script, launch it from the terminal and receive an email with the result. All in the same window, without switching context, with the same shortcuts, the same typography and the same theme. I could even add a fourth column with a Git client to version the script and push it to a remote repository. Or while we're at it, a fifth column with my favorite AI agent, able to read both my code and the rest of the panels.

We have just created an interface.

But this wouldn't be the most useful part: the programs would be integrated with each other, each one living in its own scope and, at the same time, in a global one. That means that if I enable the spell checker in the code editor with a certain configuration, it also becomes active in the terminal, in the email client when composing messages, or when I write commits. All with the same interactivity and configuration. They are not four isolated binaries connected with pipes: they are programs written in the same language, running on the same runtime and sharing the same event bus.

We have just created a connector.

Now let's remove an unnecessary layer: the bash script. If I already have an interpreter embedded in this very window, I can create my own scripts. I don't need an external binary. I no longer need to leave the window, nor touch the operating system. All my scripts, prototypes and workflows can live together.

We have just created a habitat.

There's only one problem left with the runtime: tomorrow I'll change laptops, or I'll want to work from a server, and I have no intention of rebuilding my environment from scratch. I want my scripts to work exactly the same regardless of the operating system and the hardware. A script should behave the same way on Windows, on a Raspberry Pi or on a cheap Android device. I need the whole environment to be a cross-platform runtime with bytecode that runs anywhere.

We have just created a virtual machine.

Now, to round off the idea, we'll use Lisp as the scripting language and we'll call the whole thing Emacs. Although I prefer to call it something else: a Lispboard. Like an electronics breadboard, a board where every module you plug in shares a bus with all the others, except here the modules are written in Lisp.

And if during this exercise you thought "this sounds familiar: tabs, applications and a cross-platform virtual machine… that's my browser", hold on to that intuition. We'll come back to it at the end of the article.

With everything mentioned so far, I want to debunk some myths surrounding Emacs:

What it is: a Lisp interpreter and a framework that run on top of the operating system in the most agnostic way possible, and that reimplement a good part of the programs it offers.

When you think: "I'm going to write a simple bash script to automate a task", I think: "I'm going to write an Elisp function". And on top of that, I'll give it a graphical interface if I need flags or text input.

For example, suppose you need to create a script for yourself, not for a CI/CD process or cron. The goal is to back up a specific folder (maybe to the cloud). You could end up with a command like this:

But you also include a flag to create a zip:

Well, instead of going through the terminal, I create an Elisp function that does the same thing, and I add a small panel to it.

And a buffer will show up with an interface like this:

With inputs, checkboxes and buttons. Without having to remember where it was, or its parameters, or their order.

If you have worked with Lisp before, you'll see the code is very basic:

And this scales beyond toys. With this same approach I have built systems of all kinds. For example, this blog's newsletter: I manage subscribers, generate the emails' HTML from org files, send them out, send myself previews and analyze the data. All in Elisp, local, and with a simple control panel integrated with other tools.

The key of the example is that I'm not writing a script for an operating system or an interpreter, but a function for my working environment. I'm building a new workflow, in a space where I can program my own tools, connect them to each other or build one on top of another. I could create an asynchronous notification system to alert me when something finishes, and later connect it to the previous tool at no cost.

And I can do all of this because I have an embedded scripting language, a set of libraries (like widget.el to build graphical interfaces) and a cross-platform runtime that guarantees my scripts will work the same on any operating system. That is a Lispboard.

I want to stress that I separate tasks or environments by tabs. And inside each tab I have a layout with the buffers (or software) I need.

In the IDE tab I usually open:

Although I keep weaving in temporary ones such as the file manager (Dired, with or without TRAMP), the terminal (vterm), the HTTP client (verb), Docker (docker.el), the web browser (eww) or the project manager (Projectile).

Working in Emacs with this level of integration is a pleasure that's hard to describe. You understand why it makes those who program in it fall in love.

Everything I think, plan or study ends up in plain text. The foundation is org-mode: notes, tasks and planning. On top of it, I manage my study notes with Denote: each note is a file with the metadata in its own name, all linked to each other. And when the study material is a PDF or an EPUB, I read it without leaving, with pdf-tools or nov.

Around them orbit small pieces that complete the routine, like jit-spell underlining my mistakes on the fly (remember the spell checker you configure once and it works everywhere? This is it) and wallabag to read or save articles I want to study later, calmly.

Although it may not seem like it, over the decades the community has built an excellent pack of communication tools. Even for the same protocol there are several implementations, and each one has its advantages.

In my case, I have a tab exclusively for email with mu4e. It covers every need I can expect from an email client: composing, replying, forwarding, filtering, searching, tagging, marking as read/unread, etc. And it had better do it well, because it's the most important communication channel I have: mailing lists, discussions around a Pull Request, messages from other developers, service notifications, and everything that comes with a personal and professional life.

In another tab I keep a set of chats:

I only leave for Teams and Discord, both communication channels at my job. And WhatsApp, whose use in Emacs still doesn't convince me.

My main source of information is RSS with Elfeed, almost all personal blogs. I use clients for the aggregators, hackernews-modern and lobsters (both made by me). With Gnus I read some Usenet newsgroups (it's still alive, and it reads wonderfully) and with Elpher I wander around Gemini and Gopher. When I want to open a web link, I give eww, the Emacs web browser, a chance. If it's unreadable, then I go to Firefox or the like (I have a shortcut).

The workday is more pleasant with some music playing, hence EMMS backed by mpv. And when I want to disconnect for a while, I like playing chess with chess, either alone or with a friend online. After all, the board is also there to have fun.

The community has an expression for this way of working: living in Emacs. People have been writing about it for decades, and at the end of the article I leave you the readings that have marked me the most. But notice that living in Emacs describes a habit; what I have tried to show you is the consequence. Everything you've seen is not a collection of programs, it's a single board where every module shares a bus with the rest. An interface, a connector, a habitat and a virtual machine (literally: Elisp compiles to bytecode). A Lispboard to play with, or to make your work more efficient.

Its rival is the web browser. It meets more of the requirements than we like to admit: it's a cross-platform virtual machine (for JavaScript) and half of humanity lives inside it, with their email, their chat, their music and their office suite. But it fails at the essential part: tabs are silos that don't share a bus, you can't wire your email to your chat, and no module is yours: each one belongs to a third party that can change it, fill it with ads or shut it down tomorrow. On top of that, access to the host itself is limited: it's not easy to touch the disk or talk to the operating system. The browser is a rented Lispboard, with a landlord. Emacs is the only one you can own.

To wrap up, I want to make clear that using Emacs is not nostalgia: it's that nothing comparable has appeared yet. The 0.1% of us who use it and squeeze it daily do so because it lets us work in a way no other software allows. We will probably have a lifelong relationship with our configuration. There's always something to tweak, improve or automate. And if there isn't, we create it. Emacs is not free because of its GPL license, but because it's the only place where you can live and work your way.

This work is under a Attribution-NonCommercial-NoDerivatives 4.0 International license.

This is how I keep writing without ads or paywalls.

Source: Hacker News — This article was automatically imported from the source. Read full article at original source →