Why Emacs

Emacs is the most comprehensive computing environment I've ever heard of. Its power comes from two traits that interact constructively:

  1. Emacs addresses the problem of editing text
  2. Emacs is built using a language-centric approach

Editing Text

Editing text lies at the core of many computing tasks. Any sort of writing, including programming, outlining, taking notes, authoring documentation, or writing a book, is fundamentally a form of text editing. These tasks all benefit from a common set of editing tools.

Even tasks that are not intrinsically writing-related benefit from these abstractions, as it turns out. A user can apply many of the same editing tools to file management, for example, and the result is both easy to use and powerful. Dired, a directory editor in Emacs, loads a directory of files and treats both their names and metadata as text, allowing users to use standard text editing tools on the directory listing. Tasks that otherwise require scripting or specialized tools, like bulk editing of file names, permissions, or mode, are instead treated as simple bulk text editing actions. Put simply, Dired allows a user to do amazing things like search and replace across a list of file names and metadata, and when the changes are to the user's satisfaction, commit them to disk.

This same pattern is present across many other tasks as well: email, media playback, web browsing, outlining, spreadsheets, reading newsgroups, running subshells, reading RSS feeds, and managing version control systems.

Essentially, if a task can be expressed in terms of a text-based interface, Emacs allows a user to apply a huge existing tool set to that task. For people that know Emacs, having an Emacs mode for a task confers almost instant expertise. This is a lot of fun, because it makes complex tasks easy, and also instills a feeling of power.


Emacs is built in a novel way. Its foundation is a lisp virtual machine that defines a variety of editing and application primitives that are made available to lisp code that runs within that machine. This includes objects like buffers, selections, overlays, windows, and frames. Essentially, if this foundation were shipped alone, it would be an interpreter for a dialect of lisp that includes a robust standard library tuned for editing text. But only about 20% of the code in Emacs is this foundation. The remaining 80% is devoted to crafting an editor from the primitives provided by that virtual machine. The result is then exposed to the user directly, including full access to the underlying machine as a whole.

This is extremely cool.

Emacs is the only editor I know of that adopts a language-centric approach to creating an application: write a language good for writing text editors, then write a text editor in that language. This approachs allows Emacs users to not only redefine how existing functionality works, but also write programs that implement new functionality using all those primitives. The Emacs community leverages this freedom to delightful effect: the ELPA and MELPA repositories are filled with enhancements, extensions, and entire applications for Emacs that allow other Emacs users to build the ideal workflow for themselves.

This language-centric approach is no accident; Emacs embraces it. For example, Emacs has a feature that allows the user to put the point (Emacs' name for the cursor) at the end of a parenthetical expression and press C-x C-e. If the user does this, Emacs will treat that expression as a lisp expression and attempt to evaluate it, no matter what it does. It also makes this functionality available via M-:. This means a user can modify Emacs' behavior instantly, anywhere, at any time, to suit their needs.

By providing users with full access to the underlying framework, Emacs blurs, or even eliminates, the traditional separation between a developer and a user. I mostly use Emacs to accomplish a task for work or a hobby, but sometimes out of necessity (or fun!) I use Emacs to change Emacs as I'm using it. I alter cosmetic aspects, like color theme and font, but also make bigger changes, like installing new frameworks for Emacs and using them to build a programming environment customized to my needs and preferences. A chief example of this is Hydra, which seems simply arcane first encountered, but upon closer inspection, it becomes clear how one can build their own custom workflows with it in a few minutes. My hydras provide near-instant access to all my favorite functions from across all my favorite tools, and also give me a simple mechanism for invoking my own functions written in elisp.

This kind of customizability lends itself to a very particular personality quirk I (and I assume many others) have: when something annoys me (usually because it is highly repetitive or otherwise inefficient), I like having the freedom to fix it. Most desktop applications don't really allow this, and it is almost unprecedented in the age of graphical interfaces for it to be provided in the application itself, particularly with the extremley fast feedback Emacs provides. Once I discovered this, I started building my environment in it, and I found that it started to feel like home. Things are placed exactly where I need them, and it's comfortable. For me, it just makes computing more fun.