VOMPECCC: A Modular Completion Framework for Emacs

Completion is not a feature. It is a system — one composed of at least half a dozen orthogonal concerns that most users never think about separately. This post introduces VOMPECCC, a loose acronym for eight packages that, together, form a complete, modular, Unix-philosophy-aligned completion framework for Emacs: V​ertico, O​rderless, M​arginalia, P​rescient, E​mbark, C​onsult, C​orfu, and C​ape. Each package does one thing. All eight compose through Emacs's standard APIs. And any subset works without the others.

Emacs completion is at least six orthogonal problems. VOMPECCC is eight independent packages — Vertico, Orderless, Marginalia, Prescient, Embark, Consult, Corfu, Cape — each handling one concern, all built on Emacs's native APIs. Any subset works, any component can be swapped, and nothing breaks.

When you press M-x and start typing, what happens next seems simple: a list appears, you pick something, it runs. But beneath that interaction lies a system of surprising depth. Consider what a fully featured completion experience actually requires:

Completion is not one problem. It is at least six, and most frameworks pretend otherwise.

Candidate display. Where do completion candidates appear? In the minibuffer, vertically? Horizontally? In a separate buffer? In a popup at point? The display layer determines how you scan and navigate candidates — and the optimal display varies by context. Switching buffers might want a vertical list; completing a symbol in code might want a popup near the cursor.

Filtering. How does your input match against candidates? Prefix matching is the simplest: find-f matches find-file. But what about fuzzy matching, where ff matches find-file? What about splitting your input into multiple components and matching all of them in any order? What about mixing strategies — one component as a regexp, another as an initialism?

Sorting. Once you have your filtered candidates, in what order do you see them? Alphabetically? By string length? By how recently you selected them? By frequency of use? A good sorting strategy means the candidate you want is almost always within the first few results. A bad one means scrolling every time.

Annotation. A bare list of candidate names is often insufficient. When selecting a command, you want to see its keybinding and docstring. When selecting a file, you want to see its size and modification date. When selecting a buffer, you want to see its major mode and file path. Annotations transform a list of strings into a list of informed choices.

Actions. Selecting a candidate is the most common action, but not the only one. What if you want to delete the file instead of opening it? Kill the buffer instead of switching to it? Describe the function instead of running it? A completion system without contextual actions forces you out of the flow: complete, exit, invoke a separate command.

In-buffer completion. Everything above applies to the minibuffer — the prompt at the bottom of the screen. But completion also happens inside buffers: symbol completion while writing code, dictionary words while writing prose, file paths while editing configuration. In-buffer completion has its own display requirements (a popup near the cursor, not the minibuffer) and its own backend requirements (language servers, dynamic abbreviations, file system paths). A truly complete completion system must handle both contexts.

These six concerns are orthogonal. The way you display candidates has nothing to do with how you filter them. The way you sort them has nothing to do with what actions you can take. And in-buffer completion is an entirely separate context from minibuffer completion. Any system that collapses all of these into a single package is either ignoring some of them or coupling things that should not be coupled.

For the better part of a decade, two frameworks dominated Emacs completion: Helm and Ivy. Both were genuinely transformative — they proved that Emacs's built-in completion experience was inadequate, and they inspired everything that followed. But both, in retrospect, made the same architectural trade-off: they bundled every concern into a single package with a proprietary API. The benefits were immediate; the costs emerged over time.

VOMPECCC is not a framework in the traditional sense. There is no single repository, no shared dependency, no coordinating package. It is eight independent packages, maintained by three different developers, that compose through Emacs's standard APIs to cover every concern of a complete completion system.

The architecture maps cleanly onto the six concerns identified earlier:

                Minibuffer                     Buffer
                ----------                     ------
Display:        Vertico                        Corfu
Filtering:      Orderless          (shared across both)
Sorting:        Prescient          (shared across both)
Annotations:    Marginalia         (shared across both)
Actions:        Embark             (shared across both)
Backends:       Consult                        Cape

Each package targets a single layer. Each layer communicates through standard Emacs APIs: completing-read, completion-styles, completion-at-point-functions, annotation functions, and keymaps. No package knows about the others' internals. All of them can be replaced without affecting the rest.

Vertico (VERTical Interactive COmpletion) provides a vertical candidate list in the minibuffer. It is roughly 600 lines of code, excluding its extensions. It replaced Selectrum, which was deprecated in its favor because Selectrum deviated from the completing-read API and couldn't properly handle dynamic completion tables⁸.

Vertico's defining characteristic is strict adherence to the completing-read contract. It doesn't filter candidates (that's your completion style's job). It doesn't sort them (that's your sorting function's job). It doesn't annotate them (that's your annotation function's job). It displays them. Any command that calls completing-read — whether built-in or third-party — automatically gets Vertico's UI with zero configuration.

Vertico ships with 13 built-in extensions that modify the display behavior:

vertico-multiform is particularly powerful: it lets you configure different display modes per command or per completion category. File completion could use the flat display while M-x uses the default vertical list. Buffer switching could open in a separate buffer while symbol completion stays in the minibuffer.

The vertico-multiform extension is particularly worth configuring: it lets you set per-command display modes, so consult-line can open in a full buffer while M-x stays in the minibuffer.

Created: April 2021. Stars: ~1,800. Available on: GNU ELPA.

Orderless is a completion style — it plugs into Emacs's completion-styles variable, the standard mechanism for controlling how user input is matched against candidates. Where built-in styles like basic require prefix matching and flex does single-pattern fuzzy matching, Orderless splits your input into space-separated components and matches candidates that contain all components in any order.

Each component can independently use a different matching method:

Style dispatchers let you select a matching method per component using affix characters: =​= for literal, ~ for flex, , for initialism, ! for negation, & to match annotations. The system is fully extensible.

The typical configuration sets completion-styles to '(orderless basic), with partial-completion for the file category so that ~/d/s expands path components like ~/Documents/src. The fallback to basic is deliberate: some Emacs features (TRAMP hostname completion, dynamic completion tables) require a prefix-matching style.

Because Orderless is a standard completion style, it works with any completion UI that uses Emacs's completing-read API: Vertico, Icomplete, the default *Completions* buffer, and even the minibuffer in Emacs's stock configuration.

Created: April 2020. Stars: ~979. Available on: GNU ELPA.

Marginalia adds contextual, colorful annotations to minibuffer completion candidates. The name refers to notes written in the margins of books — here, it means metadata displayed alongside each candidate.

Marginalia detects the category of the current completion (files, commands, variables, faces, buffers, bookmarks, packages, etc.) and selects an appropriate annotator function. The detection works through two mechanisms: marginalia-classify-by-command-name (lookup table keyed by calling command) and marginalia-classify-by-prompt (regex matching against the minibuffer prompt text).

marginalia-cycle (typically bound to M-A) lets you cycle between annotation levels: detailed, abbreviated, or disabled entirely. This is useful when annotations are consuming screen space during narrow completions.

Marginalia hooks into Emacs's annotation-function and affixation-function properties in completion metadata. This means it works with any completion UI that respects these properties — no special integration code needed. It is the framework-agnostic successor to ivy-rich⁹, which provided similar annotations but was Ivy-specific.

Created: December 2020. Stars: ~919. Available on: GNU ELPA.

Prescient provides intelligent sorting and filtering of completion candidates based on recency and frequency of use. Where Orderless answers "which candidates match?", Prescient answers "in what order should they appear?"

The sorting is hierarchical:

1. Recency — most recently selected candidates appear first
2. Frequency — frequently selected candidates next, with scores that decay over time
3. Length — remaining candidates sorted by string length (shorter first)

Usage statistics persist across Emacs sessions via prescient-persist-mode, which writes to a save file. This means Prescient learns your habits: if you frequently run magit-status from M-x, it surfaces near the top after a few uses, regardless of where it falls alphabetically.

Prescient ships as a core library plus framework-specific adapters — vertico-prescient and corfu-prescient being the relevant ones for VOMPECCC (adapters for Ivy, Company, and Selectrum also exist for other stacks).

A common and powerful configuration combines Orderless for filtering with Prescient for sorting. Among the candidates filtered by Orderless, the most recent and frequent ones get promoted to the top:

Prescient also provides its own filtering methods (literal, regexp, initialism, fuzzy, prefix, anchored) with on-the-fly toggling via M-s prefix commands. However, many users prefer Orderless for filtering and use Prescient purely for its sorting intelligence.

Created: August 2017. Stars: ~695. Available on: MELPA.

Embark provides a framework for performing context-sensitive actions on "targets" — the thing at point or the current completion candidate. Think of it as a keyboard-driven right-click context menu that works everywhere in Emacs: in the minibuffer, in normal buffers, in Dired, in help buffers.

The core command is embark-act. When invoked, Embark determines the type of the target (file, buffer, URL, symbol, command, etc.) and opens a keymap of single-letter actions appropriate to that type:

There are over 100 preconfigured actions across all target types.

Beyond embark-act, Embark provides several other capabilities:

• embark-dwim runs the default action without showing the menu
• embark-act-all applies the same action to every current candidate (e.g., kill all matching buffers)
• embark-collect snapshots current candidates into a persistent buffer
• embark-live creates a live-updating collection that refreshes as you type
• embark-export exports candidates into the appropriate Emacs major mode: file candidates become a Dired buffer, grep results become a grep-mode buffer (editable with wgrep), buffer candidates become an Ibuffer buffer
• embark-become switches to a different command mid-stream, transferring your input

Embark is a difference of kind, not quantity, compared to Helm and Ivy's action systems — because it works everywhere, across all types of objects¹⁰.

The embark-consult integration package connects Embark with Consult: exporting consult-ripgrep results gives you a wgrep-editable grep buffer. This workflow — search with Consult, export with Embark, edit with wgrep — is one of the most powerful patterns in the modern Emacs ecosystem.

Created: May 2020. Stars: ~1,200. Available on: GNU ELPA.

Consult provides 50+ enhanced commands built on completing-read. It is the spiritual successor to Counsel (from the Ivy ecosystem) but designed to work with any completion UI. Where Counsel called ivy-read directly, Consult uses the native contract, which means its commands work with Vertico, Icomplete, fido-mode, or even Emacs's default completion buffer.

Consult's commands span several categories:

Search:

Navigation:

Editing and miscellaneous:

Three features make Consult particularly powerful:

Live preview: Most commands show a real-time preview as you navigate candidates. consult-line highlights the matching line in the buffer. consult-theme applies the theme before you select it. consult-goto-line scrolls to the line as you type the number.

Narrowing and grouping: consult-buffer combines buffers, recent files, bookmarks, and project items into a single unified list. Narrowing keys filter to a single source: b SPC for buffers, f SPC for files, m SPC for bookmarks. Custom sources can be added via consult-buffer-sources.

Two-level async filtering: Commands like consult-ripgrep split input at #: everything before it goes to the external tool as the search pattern, everything after it filters the results locally with your completion style. error#handler searches for "error" with ripgrep, then narrows to results containing "handler" using Orderless.

Created: November 2020. Stars: ~1,600. Available on: GNU ELPA.

Corfu (COmpletion in Region FUnction) is the in-buffer counterpart to Vertico. Where Vertico handles minibuffer completion display, Corfu handles the popup that appears at point when you complete a symbol while writing code or text. It is roughly 1,220 lines of code.

Corfu's defining architectural choice mirrors Vertico's: it hooks into Emacs's built-in completion-in-region mechanism rather than inventing its own backend system. Any mode that provides a completion-at-point-function (Eglot, Tree-sitter, elisp-mode, etc.) works with Corfu automatically. Any completion-style (basic, partial-completion, orderless) can be used for filtering.

This is the fundamental difference from Company, the incumbent in-buffer completion framework¹¹. Company uses its own proprietary company-backends API. Company backends don't work with completion-at-point, and Capfs don't work with Company (without an adapter). Corfu eliminates this split. Doom Emacs recognized this: Company is now deprecated in Doom in favor of Corfu, with plans to remove it post-v3¹².

Corfu ships with seven built-in extensions:

Created: April 2021. Stars: ~1,400. Available on: GNU ELPA.

Cape (Completion At Point Extensions) provides a collection of modular completion backends (Capfs) and a powerful set of Capf transformers for composing and adapting them. If Corfu is the frontend (how completions are displayed), Cape is the backend toolkit (what completions are available).

Cape provides 13 completion backends. The ones you'll reach for most often:

The remaining backends cover dictionary words, emoji, abbreviations, line completion, and Unicode input via TeX, SGML, and RFC 1345 mnemonics.

Cape's Capf transformers are higher-order functions that wrap and modify backends:

• cape-capf-super merges multiple Capfs into a single unified source
• cape-capf-case-fold adds case-insensitive matching
• cape-capf-inside-code / cape-capf-inside-string / cape-capf-inside-comment restrict activation to specific syntactic regions
• cape-capf-prefix-length requires a minimum prefix before activating
• cape-capf-predicate filters candidates with a custom predicate
• cape-capf-sort applies custom sorting

The cape-company-to-capf adapter converts any Company backend into a standard Capf — without requiring Company to be installed. This bridges the two ecosystems: you can use Company-era backends (like company-yasnippet) with Corfu.

Created: November 2021. Stars: ~760. Available on: GNU ELPA.

The most important property of VOMPECCC is that any subset works. You don't need to buy into all eight packages. You can start with one, add another when you feel a gap, and swap any component for an alternative without breaking anything else.

This works because every package communicates through the native Emacs APIs rather than depending on each other's internals. There are no hard dependencies between any of the eight packages. Here is a map of what each package can be replaced with — or simply omitted:

Some practical subset configurations:

Minimal (2 packages): Vertico + Orderless. You get a vertical candidate list with multi-component matching. No annotations, no actions, no enhanced commands — but a dramatically better M-x and find-file experience than stock Emacs.

Comfortable (4 packages): Vertico + Orderless + Marginalia + Consult. Now you have annotations on every candidate and enhanced commands with live preview. This is probably the sweet spot for most users.

Full stack (8 packages): All of VOMPECCC. Complete coverage of both minibuffer and in-buffer completion, with intelligent sorting, contextual actions, and modular backends.

The key insight is that "full stack" is not a prerequisite. Each package adds value independently. You never need to understand all eight before starting.

For reference, here is a consolidated configuration for the full stack:

;; --- Minibuffer display ---
(use-package vertico
  :ensure t
  :init (vertico-mode)
  :config
  (vertico-multiform-mode)
  (setq vertico-multiform-commands
        '((consult-line buffer)
          (consult-ripgrep buffer)
          (consult-imenu reverse))))

;; --- Filtering ---
(use-package orderless
  :ensure t
  :config
  (setq completion-styles '(orderless basic)
        completion-category-overrides
        '((file (styles partial-completion)))))

;; --- Annotations ---
(use-package marginalia
  :ensure t
  :bind (:map minibuffer-local-map ("M-A" . marginalia-cycle))
  :init (marginalia-mode))

;; --- Sorting ---
(use-package prescient :ensure t :config (prescient-persist-mode))
(use-package vertico-prescient :ensure t :after vertico :config (vertico-prescient-mode))

;; --- Actions ---
(use-package embark
  :ensure t
  :bind (("C-." . embark-act)
         ("C-;" . embark-dwim)
         ("C-h B" . embark-bindings)))

;; --- Enhanced commands ---
(use-package consult
  :ensure t
  :bind (("C-x b" . consult-buffer)
         ("M-g g" . consult-goto-line)
         ("M-g i" . consult-imenu)
         ("M-s l" . consult-line)
         ("M-s r" . consult-ripgrep)
         ("M-y" . consult-yank-pop)))

;; --- Embark + Consult integration ---
(use-package embark-consult
  :ensure t
  :after (embark consult)
  :hook (embark-collect-mode . consult-preview-at-point-mode))

;; --- In-buffer completion ---
(use-package corfu
  :ensure t
  :init (global-corfu-mode)
  :config
  (setq corfu-auto t
        corfu-auto-delay 0.2
        corfu-quit-no-match 'separator))

(use-package corfu-prescient :ensure t :after corfu :config (corfu-prescient-mode))

;; --- In-buffer backends ---
(use-package cape
  :ensure t
  :init
  (add-hook 'completion-at-point-functions #'cape-dabbrev)
  (add-hook 'completion-at-point-functions #'cape-file)
  (add-hook 'completion-at-point-functions #'cape-elisp-block))

The history of Emacs completion frameworks is a progression from monolithic solutions toward composable ones.

GitHub stars tell part of the story, but not all of it. Helm and Ivy accumulated stars over a longer period; the newer packages are growing faster relative to their age (counts as of early 2026):

The community momentum is clear. Doom Emacs, one of the most popular Emacs distributions, has moved to Vertico + Corfu as its defaults¹³. Modern configuration guides almost universally recommend the modular stack¹⁴. And the upstream Emacs project itself has been integrating ideas from this ecosystem: Emacs 30 added completion-preview-mode, and Emacs 31 is incorporating Mct-inspired features.

Engineering is about trade-offs. The modular approach has real advantages, but it also has real costs. Here is an honest accounting.

I came to this stack the way most people probably do: one package at a time, over the course of a year or so. I started with Vertico and Orderless because my Ivy config had started fighting with Emacs 28 upgrades and I was tired of debugging someone else's ivy-read edge cases. Two packages, ten minutes of configuration, and M-x already felt better. Marginalia came next — once you've seen keybindings and docstrings next to every command, you can't unsee their absence. Consult replaced Counsel, Embark replaced the "exit completion, run a different command" dance, and Corfu replaced Company when I realized the same Orderless filtering I'd grown to depend on in the minibuffer wasn't available in my code buffers.

The whole migration happened incrementally, which is the point. I never sat down to "install VOMPECCC." I solved one friction at a time, and each solution composed with the ones I already had. That's the experience the architecture is designed to produce.

Nobody calls it VOMPECCC in Emacs circles — the name is mine, a mnemonic for an article, not a brand. But the packages it describes have quietly become the default recommendation for modern Emacs completion, adopted by Doom Emacs, recommended by Protesilaos Stavrou¹⁵, documented by System Crafters¹⁶, and built on by a growing ecosystem of third-party packages.

The shift from Helm to Ivy to the modular stack follows a familiar pattern in software: monoliths are convenient until they aren't. Composable tools with clear interfaces outlast the frameworks that try to be everything¹⁷. Emacs figured this out forty years ago. Its completion ecosystem just needed a few years to catch up.