Completion is a Substrate, not a UI | Charlie Holland's Blog

Skip to main content<br>Completion is a Substrate, not a UI<br>Completion is a Substrate, not a UI<br>April 14, 2026

© 2026 Charlie Holland

Completion is a Substrate, not a UI

Completion is a Substrate, not a UI

Table of Contents

1. About   emacs completion ux

2. What is Incremental Completing Read?   ICR HCI

3. The ubiquity of ICR   ux

4. A thought exercise: how much of computing fits inside ICR?   composition shell HCI

5. The cognitive cost argument   cognitiveStrain

6. Recognition, recall, and the third option   psychology

7. Flat over nested: how ICR reshapes how you organize   organization knowledgeManagement

8. Why ICR matters more in Emacs than anywhere else   emacs

9. Where this series goes

10. tldr

1. About   emacs completion ux

Figure 1: JPEG produced with DALL-E 3

ICR is not a convenience feature. It is a structural change in how the cost of an interaction scales with the size of the underlying data.

The argument I want to make is sharper than it sounds. Incremental completing read (ICR) is not a convenience feature. It is a structural change in how the cost of an interaction scales with the size of the underlying data; it is one of the few interface patterns that genuinely respects how human memory works; and it can fortuitously change how you organize your data, not just how you retrieve it.

A brief thought exercise reveals how a surprisingly large fraction of all software — email, calendars, file browsers, music players, issue trackers, package managers — is, at its core, just two primitives: 1) pick a thing, 2) act on it. That is the exact shape ICR was built for, and most of the visual chrome we drape around those primitives is decoration.

This matters concretely because very few environments expose completion as a programmable substrate1 you can build ICR experiences with, rather than as a sealed UI you can only consume. In everything else you use, the candidate sources, the matcher, the sorter, the annotator, and the available actions are largely fixed by the vendor or aren't even available. On the other hand, in Emacs and the shell, every layer is independently replaceable. Taking your completion stack seriously is among the highest-leverage things an Emacs user can do, on the same scale as customizing your shell, and for the same reasons. Done right, ICR can dramatically reduce the cognitive overhead of using your computer to do almost anything.

This post opens a short series on ICR. The remaining two posts get concrete: a breakdown of the modular completion framework I use day to day, and a case study of an entire Spotify client that is just an ICR application. The goal of this opening piece is to convince you that ICR is worth your rigor, and to give you the conceptual vocabulary to recognize how much of your own software experience already runs on it.

2. What is Incremental Completing Read?   ICR HCI

"Incremental Completing Read" has three load-bearing words:

Read , in the elisp sense: a function that prompts the user and returns a value. The system asks a question, you answer, and then the answer is something other code can do something with.

Completing : the system maintains a candidate set and shows you which candidates currently match your input. You don't type the full answer. You type enough to disambiguate, and the system fills in the rest.

Incremental : the candidate set is recomputed on every keystroke2. You don't submit a query and wait for results. Filtering happens between characters, fast enough that the result list feels like an extension of what you're typing.

Combine the three words and you get an interaction that is qualitatively different from either browsing or searching. Browsing scales poorly to large sets — you can scan a list of ten things, not a list of ten thousand. Search-and-submit scales fine in the back end but introduces a feedback gap that breaks flow. ICR fuses the two.

A clarification before going further. In Emacs, the standard-library function named completing-read is not, on its own, incremental. It TAB-completes at the minibuffer and shows a *Completions* buffer on demand. The incremental UX described above is layered on top by a separate generation of frontends like Icomplete, Ido, Ivy, Helm, and the modern Vertico. Throughout this series, "ICR" refers to the pattern (the API plus an incremental frontend), not to any single function. This separation matters because it makes the Emacs completion stack pluggable, and this separation is the subject of the next post in the series.

3. The ubiquity of ICR   ux

Think about all the places you already use ICR. Here's a partial inventory:

The browser URL bar narrows history and bookmarks as you type.

Search engines suggest queries character by character.

Spotify, Apple Music, and YouTube surface tracks, artists, and videos as you fill in the search box.

Amazon's product search shows partial matches and category filters...