May I recommend… understanding Emacs's patterns
#Regulation

May I recommend… understanding Emacs's patterns

Tech Essays Reporter
4 min read

Charlie Holland reflects on the two central patterns that make Emacs feel effortless – Incremental Completing Read (ICR) and the recognize‑dispatch model – and explains how they create a unified, fan‑in/fan‑out architecture that lets users work across any language or tool without the friction of disparate GUIs.

May I recommend… understanding Emacs's patterns

Published May 14, 2026

{{IMAGE:1}}

1. Introduction – why Emacs feels effortless

Holland opens with a Shakespeare‑inspired soliloquy to set the tone: Emacs is not a mystical wand but a collection of patterns that, when composed, make everyday computer work feel effortless. He argues that the common perception of Emacs as arcane stems from a misunderstanding of these patterns rather than any inherent complexity.

2. The two core patterns

2.1 Incremental Completing Read (ICR)

ICR is the minibuffer completion system that filters a candidate list as you type. Packages such as Orderless, Vertico, and Selectrum extend the basic mechanism with fuzzy matching, recency‑based ranking, and dynamic narrowing. The key ideas are:

  • Recognition over recall – you need only type enough of a candidate’s shape to shrink the list.
  • Uniform entry point – every domain (files, buffers, commands, LSP symbols, URLs, etc.) presents its choices through the same minibuffer, creating a fan‑in of all possible actions.
  • Live feedback – the list updates on each keystroke, turning a potentially overwhelming search into a trivial, cognitive‑light operation.

2.2 Recognize‑dispatch (typed‑thing actions)

Packages like Embark and Hyperbole expose a type for any piece of text under point (file path, symbol, URL, region, etc.). Each type has a menu of verbs (open, rename, copy, search, send to LLM, etc.). The pattern works because:

  • Extensible type system – new types can be added by any package, and existing types can be enriched with additional actions.
  • Uniform dispatch – the same embark-act command works everywhere, turning the editor into a fan‑out of possible operations.
  • Composability – actions can themselves invoke other typed‑thing commands, enabling pipelines reminiscent of Unix shells.

3. The “bow‑tie” metaphor

Holland first used a rose metaphor (roots → buffer, petals → applications) but later adopts Gwern Branwen’s bow‑tie analogy. In a bow‑tie network, many inputs fan in to a narrow set of intermediates (the “knot”), which then fan out to many outputs. In Emacs:

  • Knot 1 – the buffer – every piece of content is a buffer of characters with text properties. All editing primitives operate on this universal substrate.
  • Knot 2 – ICR – the minibuffer completion engine narrows any candidate set to a manageable few.
  • Knot 3 – Embark/Hyperbole – the typed‑thing dispatch layer maps any noun to an extensible verb set.

These knots are stacked, each providing its own fan‑in/fan‑out, and together they give Emacs its “effortless bloom”.

4. Real‑world examples

  • Language Server Protocol (LSP) – via eglot or lsp-mode, the editor receives type information from an external server and plugs it into the same buffer‑based model, letting you go to definition, find references, or rename without leaving Emacs.
  • RSS with elfeed – all feeds are collected into a single elfeed-search buffer (fan‑in); navigation, filtering, and actions (open, tag, export) reuse the same ICR and dispatch mechanisms (fan‑out).
  • Email with mu4e – multiple accounts converge into a unified mailbox view; again, the same buffer‑centric commands apply.

5. Why the patterns matter beyond Emacs

Holland acknowledges that the patterns are not exclusive to Emacs. VS Code’s command palette, Sublime’s “Goto Anything”, and other editors’ plugin systems echo ICR and typed‑thing ideas. However, the composition of these patterns – a single Lisp‑based extension language, a universal buffer model, and a community that embraces inspectability – gives Emacs a coherence that is hard to replicate.

6. Implications for tool builders

  1. Design for a narrow universal substrate – Choose a representation (text buffers, JSON trees, etc.) that all features can share.
  2. Expose a single, recognisable entry point – A minibuffer‑style selector reduces cognitive load across domains.
  3. Make actions extensible and type‑aware – Allow developers to register verbs for any noun, enabling future composability.
  4. Encourage a culture of hooks and redefinition – The more the community can inspect and modify behaviour, the richer the emergent patterns become.

7. Counter‑perspectives

  • Some users argue that the learning curve of Emacs stems from its vast ecosystem rather than any conceptual opacity. While the patterns reduce friction once they are understood, the initial exposure still requires deliberate onboarding.
  • Critics point out performance concerns: heavy ICR pipelines and large dispatch menus can become sluggish in massive projects. Recent optimizations in vertico and lazy loading of Embark actions mitigate this, but the trade‑off remains.
  • Finally, the “everything is a buffer” model may feel limiting for highly graphical workflows (e.g., design tools). Hybrid approaches that embed external UI widgets while preserving a textual core are an active area of experimentation.

8. Conclusion

Holland’s essay reframes Emacs not as a relic of Lisp wizardry but as a living embodiment of the fan‑in/fan‑out principle. By unifying input (ICR) and output (recognize‑dispatch) around a narrow, extensible knot, Emacs lets users pull broadly and push narrowly—or vice‑versa—without the friction that typically accompanies polyglot development. The rose may have been a whimsical metaphor, but the bow‑tie captures the essential architecture that makes Emacs feel like an effortless bloom for those who learn its patterns.


For further reading, see the original post on Charlie Holland’s blog and the referenced papers on bow‑tie networks:

Comments

Loading comments...