Cached at:
05/14/26, 02:25 AM
# May I recommend… understanding Emacs's patterns
Source: [https://www.chiply.dev/post-emacs-carnival-may](https://www.chiply.dev/post-emacs-carnival-may)
Picture a rose, a purple one if you could \(as we are talking about Emacs here\)\.
On one end, the rose has roots, pulling in nutrients and dihydrogen oxide through a complex and ever growing tendrillic network\. At the other, we see the rose's beautiful flowering of petals: the outcome of all this rose's growth, the attractor of admiring eyes, and the basis for proliferation through pollination\. Emacs's patterns, architecturally, remind me of this kind of flowering because we can see that Emacs fans\-in and fans\-out in the same beautiful and life\-giving ways as our purple rose's roots and petals do\.
Consider the buffer\. Anything you look at in Emacs \(no need to enumerate, I literally mean*everything*\) is a buffer of characters with text properties layered on top\. I'm simplifying a little bit, but that's pretty much it\. That standardization is the core data model from which everything else grows\.
The roots of the rose look the same whether they're pulling minerals from clay, soil, or sand \(it's all just water and ions in the end\)\. In Emacs,*any***thing**is pulled into just characters and properties in a buffer \(fan\-in\)\. The corollary is that every editing primitive you learn — search, kill, mark, narrow, replace, undo, blah blah blah — works against*every*piece of content you'll ever look at in Emacs, because nothing is special with respect to this data model, and no exceptions will be found\. The characters \+ text props is the unifying idea, and the buffer in which they reside offers a universal vocabulary with which you can speak into Emacs whatever your heart desires, Juliet 😉\.
On top of that vocabulary sits Elisp, and on top of Elisp sit the applications\. Whatever you can likely imagine \(Email, RSS, calendar, version control, file management, IRC, music, financial ledger, terminal, etc…\) is a small Elisp program that puts text into a buffer \(often with a specialized major\-mode\) and binds keys to commands that transform and navigate that text\.
There is no fundamental linguistic difference between something as complex as[Magit](https://magit.vc/)and something as simple as a mode I may write to depict an ASCII rose in a popup buffer\. The elisp entities powering those modes live in the same namespace, share the same APIs, and adhere to the same Emacsien and Elispien conventions\. This is the deeper meaning of 'interface unification': you don't merely view different things through one interface \(which is valuable by itself\)\. Instead, you build, extend, and rewire them*through one interface*\. And if a use case doesn't have an application yet, building one is easy, because you have the full power of Elisp\.
The next pattern lives at the input layer, and is evocative of many an 'at\-your\-fingertips' metaphor\. When Emacs asks you to choose something \(files, buffers, commands, or indeed a candidate from any context\) it doesn't ask you to remember what you're looking for verbatim\.**Incremental Completing Read**\(ICR\) drastically reduces the burden of recall when searching for anything when you're inside of Emacs, and the flexible filtering offered, for example, by packages like[Orderless](https://github.com/oantolin/orderless), make the resulting candidate set small and specific enough that recognition is often trivial\.
ICR in Emacs can take whatever set of candidates is in play and filters it live as you type, ranking by recency and[frecency](https://en.wikipedia.org/wiki/Frecency), fuzzy\-matching, re\-sorting by relevance, etc…\. When you hit M\-x \(to run a command\), you don't have to know the exact command name; you simply have to know, or perhaps more accurately 'intuit', enough of its shape to narrow the field\. And because every domain in Emacs eventually exposes its candidates through the same minibuffer mechanism, the entire universe of things\-you\-might\-want pulls through a single, deeply familiar selector \(fan\-in\)\. At runtime, you can materialize and search this universe \(fan\-out\) with only your tiny, fuzzy notion of what you're looking for\. This recall facility is something that makes using Emacs powerful, but also cognitively ergonomic\. Like with buffers \+ text \+ props, you'll find after a while that most of your Emacs usage funnels through this unified interface of minibuffer completion\.
ICR is only part of this story\. After you've selected your candidate, what can you do with it? Emacs cheekily answers "what can't you do with it\!", and more helpfully adds "let me show you*exactly*what you can do with it"\. This comes from an implementation of what I think of as the**recognize\-dispatch**pattern\.
In most software, the answer \("what can I do with this thing on the screen"\) is hardcoded to a single default action: the open\-file dialog opens files, the contact picker picks contacts, and so on\. Packages like[Embark](https://github.com/oantolin/embark)and[Hyperbole](https://www.gnu.org/software/hyperbole/)change the cardinality here for the better\.
Any "thing" \(which is a funnily loaded word in Emacs land\) on which you can place your cursor \(file path, a URL, a symbol, a region, etc…\) has a type, and that type has a menu of actions associated with it\. Because both the types and actions are extensible, Embark offers the ability to assign a specific type \(or set of specific types\) to*anything*that appears in Emacs \(fan\-in\) and enables you to take*any*action on that thing \(fan\-out\)\.
In this way, for example, a symbol is a thing you can describe, jump to, occur, rename, search the web for, hand to an LLM, ad infinitum…\. A file is a thing you can open, diff, copy a path to, rename, attach to an email, ad infinitum…\. The "infinitum" part is quite literal, especially when you consider that you can use any parameterized command as an Embark action \(you aren't limited to what's in the defined menus\)\. In this way, the actions accrue as you continue to extend Emacs\. When you install a new package \(fan\-in\), suddenly all your existing nouns, or types, gain new verbs, or actions \(fan\-out\)\.
Also consider how, with Emacs, you can achieve the same kind of piping paradigm you would with a Unix shell\. In a spiritual recovery of the 90's era[CLIM \(Common Lisp Interface Manager\)](https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager)implementation of presentation\-types, output of some command in Emacs can be input to another via this recognize\-dispatch system\. The snake eats its tail, somehow in a non self\-cannibalistic manner, just like in the all\-powerful Unix shell\.
An especially enabling set of actions that you can add in this way is provided by language servers in Emacs\. For decades, "go to definition," "find references," and "rename symbol" were the exclusive privileges of IDEs that had been hand\-coded \(and price\-tagged\) for a specific language\. The[Language Server Protocol](https://microsoft.github.io/language-server-protocol/)\(LSP\) externalizes that introspection into a per\-language server that speaks a common format\. Emacs \(via[eglot](https://github.com/joaotavora/eglot)or[lsp\-mode](https://emacs-lsp.github.io/lsp-mode/)\) talks to the server, the server reports types and locations, and Emacs renders the result into a buffer\. The upshot is that Emacs's existing typed\-thing machinery inherits the introspective powers of a language server, in every language that has one \(fan\-in\)\. The cost of literacy in a new language collapses \(yay for me\!\), because the editor doesn't have to learn anything new; only the server \(or the implementer of the server\) does\. In this way, you can effortlessly navigate, code, and execute in any language \(fan\-out\) using the same usage pattern\.
There is so much power in this pattern: recognize the noun, dispatch a verb\. Pour all instances into a single channel \(fan\-in\); radiate out from that channel with the full force of every extension you've ever installed \(fan\-out\)\.
This fan\-in, fan\-out occurs at the application level as well\. Take[elfeed](https://github.com/skeeto/elfeed), for example, the leading RSS reader in Emacs\. All the vagaries of any news source you subscribe to funnels its new items into a flat list \(fan\-in\) in an elfeed\-search buffer, and all the Emacs facilities that work in any other mode are available to you as you navigate and consume these news sources \(fan\-out\)\. As another example, take[mu4e](https://www.djcbsoftware.nl/code/mu/mu4e.html), a popular email package for Emacs\. Emails from all your email addresses, again, are funneled into a single flat list \(fan\-in\), and you have all the power of Emacs at your disposal to navigate mail, read, and respond \(fan\-out\)\.
The rose has the structure it has because it works, and many years of evolution have brought its beautiful form and function to bear\.
The bloom:
Pull broadly, push narrowly; pull narrowly, push broadly\.
With**recognize\-dispatch**, pull broadly everything into text buffers, push narrowly into an actionable type system; pull narrowly from that sparse set of typed things, push broadly into any conceivable action\.
Any search or selection you need to do inbetween is made effortless by ICR, where, by the way, types and actions are still available \(thanks to Embark\)\. Pull broadly any candidate source into Emacs and push narrowly into the minibuffer's ICR system; pull narrowly from a filtered candidate set and push broadly into any conceivable action on your selection\.
You can even see the two patterns work gracefully in concert: consider dispatching a huge action menu for a generic target\. You don't want to manually scan through the which\-key buffer to select that action, so you can use embark\-help to run ICR and select your action that way\. Beautiful\!
Emacs's patterns aren't incidental\. They're something closer to the right answer to a question every aspirationally generic tool eventually asks, which is "how do you make one interface stand in for many, without losing the specificity of any"?