Vibe-coding Brings the Power of Emacs to Everything

One of the first use-cases I found for LLMs back when ChatGPT first released was automating the creation of citations, or rather the transformations of citations structured in one way into .bib-files that can be used to create a wide variety of uniform citations in \(\LaTeX\) documents. LLMs are fantastic for this sort of work, where some sort of messily structured data needs to be transformed into some other form that is then useful. As LLMs become cheaper and cheaper it becomes easier and easier to make data become useful. The benefits of this is obvious to the point of it being the main strength of what is perhaps the world’s oldest continuously developed software project; GNU Emacs.

Much of software engineering is piping that transforms data from one form to another, where we can then process it, ingest it, or present it in some interesting and beneficial way. This is true regardless of the underlying nature of that data. In Emacs there are primarily two forms of this data: lisp code and text. Ardent lisp wizards will object on the basis that one of the core strengths of lisp is that it does not discriminate between lisp as a program qua list of instructions and lisp as a data structure due to its simple syntax.¹ The classic UNIX environment also made use of this compatibility made possible by a common language of text.

Emacs is a lisp interpreter that comes with a text editor and tools to evaluate elisp code written in said editor. This simple basis allows Emacs to very quickly and easily be extended. While other programs (and even text editors specifically) may offer theoretically similar capabilities² through scripting languages and APIs they do not offer the truly free experience that only a few Emacs-like programs build their experience upon. Most code written in Emacs is not packaged or distributed anywhere, but is made up of small and opinionated changes and functions that are likely not maintained in any way. This means that each Emacs user’s computing experience is personally tailored to his or hers own preferences.

The second of the four freedoms (freedom #1) of free software is the “the freedom to study how the program works, and change it to make it do what you wish”. In practice this only means access to the source code under a free-software license. But Emacs takes this much further; instead of a merely “negative” freedom (freedom from proprietary restrictions) it adopts a positive approach, where the user is directly given the tools and documentation³ to change each and every part of the Emacs source code.

Emacs, UNIX, and modern LLMs all make use of the unique strengths of text. Emacs however goes much further in this regard than the standard UNIX system, and in many regards can be seen as an extension and intensification of it. Tietze pointed out recently how the textual representations of almost all data in Emacs is “completes computing” through the universality of text and primarily the text buffer.

If the costs of creating software goes to zero due to continuing advancements in LLMs it would bring this quality that Emacs has to all software. The restrictions of proprietary software has always been an invention by monopolistic software companies wishing to add a shackle on what is really just a bunch of abstract logical statements. That this has been maintained is impressive, but it can not do so under the onslaught of code produced by LLMs.

Trivially creating quick and simple programs that serve the user is Emacs’ greatest strength, and it is something that will be accessible to everyone, no matter their experience in software creation. One will be able to make small little applications that serve yourself, and because of its low cost will naturally freely share them with friends, colleagues, and family members. It is, to repeat a often-used sentiment of mine, a revolution in the field of software development — a dramatic return to the older state of affairs, albeit now aided by the lessons of the time in between. In this case it is a return to the times before “free software”, when specifying that a given software was free to use, share, and modify was not necessary but expected and normal.

To reiterate, vibe coding and LLMs have two great strengths:

Easily creating, recreating, and modifying small programs that do not need to be maintained and are tailored for the user’s needs.
Formatting roughly structured data into ways that fit the user’s needs, or writing small scripts that do so.

The consequence of these to strengths is a renaissance of free software development where the user become free to construct their computing environment however they see fit. “Emacs is a great operating system, if only it came with a decent text editor” goes the famous quip; Emacs is of course not a operating system in the strict sense,⁴ but it does allow for the almost complete reshaping of one’s interactions with a computer — being able to replace most other use-facing applications. LLMs extend this freedom to outside the frame of Emacs and into almost every part of the software stack. ❦

Footnotes:

Simple in the sense of this quote by Leonardo da Vinci:

A poet knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

This simplicity does not mean that it is impossible to construct elaborate or complex programs in lisp — in fact it is one of the most expressive programming languages. Rather it refers to the basic axioms inferred from the nature of prefix notation and the structure of the abstract syntax tree itself.

What matters in theory is in fact not very interesting. Many languages and processes are Turing-complete, and could thus be used to create any other program, but what actually matters is the ease and manner of creating such a program.

Emacs has extensive manuals, but most of all it is its nature as the “self-documenting editor” that gives it this quality.

⁴

In that it does not facilitate the interaction between software and hardware.