05 Workbench & intelligence
Emacs
An editor you shape around the work, rather than the other way round.
- Role
- Editing environment
- Licence
- GPL v3
- Since
- 1985
- Upstream
- Project site ↗
Most of our work happens in Emacs. It is not the fastest editor, but it has been maintained continuously for four decades and it can be bent to the shape of the job.
Why we still choose it
A working environment is a long-term investment, and tools that make you migrate every five years impose a cost on everything you build with them. In Emacs the configuration is a program, kept in Git like anything else, so the environment moves between machines and across years without ceremony.
It also means everything happens in one place. We edit Nix expressions, read Rails codebases, write Markdown for Jekyll sites, run a shell and, more and more often, talk to a local model through Ollama, all without switching to a different application for each.
Org-mode deserves a specific mention. Notes, runbooks and literate configuration live in plain text that will still open in thirty years, which is more than can be said for most of the tools that have tried to replace it.
Where it meets the local models
Emacs makes an unreasonably good interface to a language model running on your own hardware, because it is programmable all the way down. Wiring a model into a buffer, a region or a code review takes a few lines of Lisp, with no need to wait for someone else to ship a plugin. We offer that as an engagement in its own right, alongside Ollama.
Where it falls short
The learning curve is famously steep and we do not impose it on anyone. Some people on any team will bounce off it, and that is a matter of preference. Everything we hand over works without it: runbooks export to plain Markdown, the configuration is readable in any editor, and the model endpoint is OpenAI-compatible, so a colleague can point their own tooling at the same GPU and lose nothing but our key bindings.