Freedom Is an Architecture: What GNU Emacs Gets Right That Your IDE Doesn't

Protesilaos Stavrou (prot) published a piece today on computing in freedom with GNU Emacs. Prot is a GNU Emacs developer and philosopher who maintains Denote, Modus themes, Ef themes, Pulsar, and a long list of other packages, several of which have been merged into GNU Emacs core. He writes about free software philosophy on the same website where he publishes his elisp, which is itself a kind of statement.

His framing is worth taking seriously, but I want to push past the philosophical register into something more concrete: computing in freedom is not primarily a political position. It is a consequence of a specific technical architecture. The architecture came first. The freedom is a side effect.

What Emacs Actually Is

GNU Emacs is not a text editor with a scripting API bolted on. It is a Lisp machine with a thin C runtime underneath. The C layer handles the event loop, I/O, rendering, and a handful of performance-critical operations. Everything else, including most of what you would think of as “the editor,” is written in Emacs Lisp (elisp) and evaluated at runtime.

This matters because of what it means for inspectability. When you call a function in Emacs, you can ask where that function is defined, right now, while it is running, and jump to the source. C-h f (or M-x describe-function) opens documentation for any function. M-x find-function takes you directly to the elisp source. This works for your own code, for packages you have installed, and for functions that ship with Emacs itself.

;; Find the source of `forward-word` while it is running
(find-function 'forward-word)

;; Or interactively: M-x find-function RET forward-word RET

There is no black box. The function is written in the same language you use for everything else, and the source is right there.

More significantly, you can change that function. Define a new version of it in your config, and the new version takes effect immediately. No recompile. No restart. This is M-x eval-region and M-x eval-buffer: live patching of a running editor.

;; Override a function in your config and eval-buffer to apply it
(defun my/custom-save-hook ()
  "Run formatters and linters before saving."
  (when (derived-mode-p 'python-mode)
    (py-autopep8-buffer)))

(add-hook 'before-save-hook #'my/custom-save-hook)

Evaluate that, and it is live. The editor has changed its own behavior without stopping.

The Four Freedoms as Technical Properties

The Free Software Foundation defines four freedoms: freedom 0 (run the program), freedom 1 (study how it works), freedom 2 (redistribute copies), freedom 3 (distribute modified versions). These are usually discussed in legal terms, as licensing conditions. But in Emacs they are also engineering properties baked into the architecture.

Freedom 1, the freedom to study: because the editor is a running Lisp machine with inspectable source, studying how it works is not a matter of going to find a repository and reading files. It is pressing a key combination while you are in the middle of using it. The study affordance is built into the runtime.

Freedom 3, the freedom to modify: because you can evaluate new code against the live image at any time, modifying behavior does not require forking the project or rebuilding from source. It requires writing an elisp expression and evaluating it. Your init.el is not a configuration file in the sense of a preferences JSON. It is source code that reshapes the editor it runs inside.

This is what makes the word “freedom” concrete rather than rhetorical. It is not that Emacs is licensed permissively and therefore you are theoretically free to do things with it. It is that the technical architecture makes inspection and modification the natural way to use the tool.

Comparing This to Other Editors

VS Code is the dominant editor in most developer communities right now, and the comparison is instructive. VS Code is built on Electron, which means it is a Chromium browser running a Node.js application. The extension API is deliberately sandboxed: extensions run in a separate process and communicate with the editor host through a typed message-passing interface. You cannot redefine core editor behavior from an extension. You can only call the APIs that Microsoft has decided to expose.

Settings sync sends your configuration to Microsoft’s servers by default. Telemetry is enabled by default, which you can disable, but the default matters because most people never change defaults. GitHub Copilot, the flagship AI feature, is a proprietary service. The VS Code experience is convenient and it is fast, but the locus of control sits with Microsoft, not with you.

Neovim is a closer comparison. The community is serious, the tooling is sophisticated, and Lua scripting is genuinely powerful. But Neovim itself is not written in Lua. The core is C. This means that when you want to change how something in the editor works at a fundamental level, you hit a boundary that does not exist in Emacs. You can extend Neovim; you cannot redefine it. The distinction sounds academic until you try to do something the extension API does not anticipate.

JetBrains IDEs are powerful and in many domains genuinely excellent, but they are proprietary end to end. There is no equivalent of find-function. When you want to understand how a feature works, your only option is empirical: use it and infer. The source is not available and neither is the runtime.

Cloud IDEs, GitHub Codespaces, Replit, and similar environments add another layer of dependency. The compute is rented. The tool disappears if the company pivots or shuts down or decides your account violated a policy. Your workflow depends on a network connection and a billing relationship. This is not hypothetical: services have shut down, changed pricing dramatically, or had extended outages that stranded users mid-task.

Native Compilation and What Emerged When Users Could Build

GNU Emacs 29 introduced native compilation via libgccjit. Elisp is compiled ahead-of-time to native machine code, with significant performance improvements for compute-heavy operations. This matters for packages like Magit, which implements a Git interface in pure elisp that exceeds most dedicated GUI clients in both power and clarity. Magit is possible because a user decided they wanted something better and had the access to build it from scratch, in the same language as the editor itself, with full access to every editor primitive.

Org mode is the other canonical example: a document format, a task manager, a spreadsheet, a literate programming environment, and a publishing system, all implemented in elisp and deeply integrated with the editor. This kind of integration is not achievable through a sandboxed extension API. It requires the ability to reach into the editor’s core behaviors and reshape them.

These projects emerged from a community of users who had the freedom to build deeply, not just to configure superficially. Freedom 1 and freedom 3 as technical properties produced Magit and Org mode. The licensing is what made distribution and collaboration possible, but the architecture is what made the building possible in the first place.

Prot’s Packages as a Working Demonstration

Prot’s own work is a demonstration of the principle operating correctly. Modus themes is now part of GNU Emacs core, included since Emacs 28. Every GNU Emacs installation ships with WCAG-compliant, accessibility-reviewed color themes maintained by a single person who also writes philosophy on the same website. He does not work for a company. He maintains this because the free software model allows and encourages it.

Denote is a note-taking system built on the principle that notes should be plain files with structured names, accessible without any particular software. It is available through GNU ELPA, which requires contributors to assign copyright to the FSF and ships only fully free packages. NonGNU ELPA and MELPA have different requirements and varying freedom guarantees. These distinctions matter if you care about the long-term provenance and modifiability of the code running in your editor.

The fact that a philosopher-programmer in a non-corporate setting can ship a color theme that ships with the editor used by millions of people, and maintain it to an accessibility standard that large commercial teams often fail to meet, is the free software model working exactly as intended.

Why This Matters More Now

AI coding tools are useful. I use them. But Copilot, Cursor, and similar tools are moving the development environment in a specific direction: more cloud-connected, more opaque, more dependent on services controlled by companies with their own interests. The model weights that power your coding assistant are proprietary. The telemetry sent by your editor may inform future model training. The suggestions you accept are shaped by training data you cannot inspect.

This is not an argument against using these tools. It is an argument for understanding what you are giving up and whether the tradeoff is worth it for your situation. The trend is toward less developer control over the environment, not more, and that tendency is accelerating.

The Emacs tradition offers a counterpoint that is easy to dismiss as nostalgia but is actually a coherent engineering position: a working environment where you understand every layer, where you can inspect the source of any running function, where your configuration is executable documentation that lives in version control alongside your code, and where the tool works offline, locally, and entirely under your control.

Your init.el is the program. It is not a settings file that configures a program someone else controls. Writing it is an act of authorship over your own computing environment. That is what prot means, and what the free software movement has always meant, by computing in freedom. The architecture makes it real rather than aspirational.