# cape.el: completion backends you can trigger on demand in Emacs > Cape turns a set of completion sources into completion-at-point functions, so the same completion-at-point, Corfu or Company setup can also be invoked directly from a key binding. It ships fourteen backends, can wrap a Company backend as a Cape function, and can merge several into a Super-Capf. **minad/cape** — 🦸cape.el - Completion At Point Extensions - Repository: https://github.com/minad/cape - Stars: 797 · Forks: 31 - Language: Emacs Lisp - License: GPL-3.0 - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/minad-cape ## Completion sources as first-class, invokable things Cape provides Completion At Point Extensions, and the mechanism is a list variable. The completion backends used by completion-at-point are so called completion-at-point-functions, or Capfs, and you register the cape-* functions in the completion-at-point-functions list. That makes the backends available to completion, which is usually invoked by pressing TAB or M-TAB, and the same functions can also be invoked interactively to trigger the respective completion at point. You can bind them directly to a key in your user configuration. The reason to have both paths is the one the README itself recommends, binding the cape-* commands to keys so you can invoke them explicitly, which makes particular sense for special Capfs you only want to trigger in rare circumstances. A file name completion that fires on every TAB is annoying; a file name completion on a deliberate key is a tool. ## Fourteen backends, from abbreviations to Unicode The available Capfs are listed explicitly, which makes it easy to see the coverage. cape-abbrev completes an abbreviation using add-global-abbrev and add-mode-abbrev, and cape-dabbrev completes a word from the current buffers, with dabbrev-capf as the counterpart. cape-dict completes a word from a dictionary file, cape-file completes a file name, and cape-history completes from Eshell, Comint or minibuffer history. cape-line completes an entire line from the current buffer. On the language side there is cape-elisp-symbol, cape-elisp-block, which completes Elisp in an Org or Markdown code block, and cape-keyword for a programming language keyword. The Unicode entries are the interesting ones: cape-emoji completes an emoji, cape-rfc1345 completes a Unicode character using RFC 1345 mnemonics, cape-sgml completes from an SGML entity such as &alpha, and cape-tex completes from a TeX command such as \hbar. The README notes that cape-elisp-symbol and cape-elisp-block are useful for documenting Elisp packages and configurations since they complete Elisp anywhere. ## Ordering decides which backend wins, and that is the sharp edge The configuration section warns about two things that are easy to get wrong. First, each Capf adds a small runtime cost, so adding all of them to the completion-at-point-functions list slows ordinary completion down. Second, the Capfs which occur earlier in the list take precedence, such that the first Capf returning a result will win and the later Capfs may not get a chance to run. That is a real design constraint rather than a detail, because the list is shared between the global value and the buffer-local value. The buffer-local value takes precedence, but if the buffer-local list contains the symbol t at the end, it means the functions specified in the global list should be executed afterwards. That special meaning of the value t is a feature of the run-hooks function, and the README points to the section on Running Hooks in the Elisp manual. The practical consequence is that adding a Capf in the wrong place does not produce an error, it produces a completion you did not expect. ## A configuration that binds the commands under one prefix key The README's sample configuration is based on the popular use-package macro and shows the two ways to bind the commands. You can bind a prefix keymap providing all Cape commands under a mnemonic key, with a comment that pressing C-c p ? gives help: ```elisp (use-package cape ;; Bind prefix keymap providing all Cape commands under a mnemonic key. ;; Press C-c p ? to for help. :bind ("C-c p" . cape-prefix-map) ;; Alternative key: M-, M-p, M-+ ;; Alternatively bind Cape commands individually. ;; :bind (("C-c p d" . cape-dabbrev) ;; ("C-c p h" . cape-history) ;; ("C-c p f" . cape-file) ;; ...) :init ;; Add to the global default value of `completion-at-point-functions' which is ;; used by `completion-at-point'. The order of the functions matters, the ;; first function returning a result wins. Note that the list of buffer-local ;; completion functions takes precedence over the global list. (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) ;; (add-hook 'completion-at-point-functions #'cape-history) ;; ... ) ``` The example deliberately leaves cape-history commented out of the global list while binding it as a key, which is the pattern the README recommends: rarely wanted sources stay out of the default completion path and live on their own binding instead. ## A Company backend can be used without using Company The capability the README is most pleased about is that Cape can transform Company backends into Capfs and merge multiple Capfs into a Super-Capf, so you can still take advantage of Company backends even if you are not using Company as the front end. The adapter is cape-company-to-capf, it is approximately the inverse of the company-capf backend from Company, and it works like this: ```elisp (setq-local completion-at-point-functions (mapcar #'cape-company-to-capf (list #'company-files #'company-keywords #'company-dabbrev))) ``` A detail that saves an hour of confusion: the adapter does not require Company to be installed or enabled. Backends implementing the Company specification do not necessarily have to depend on Company, even though in practice most of them do. That distinction lets you use a Company-style backend in a Corfu or plain completion-at-point setup, which is the point of the whole package, because Cape is the layer that lets a backend be invoked deliberately rather than only as part of a general completion attempt. ## A tiny package that is easy to install and easy to read The repository layout reflects how small this is. There are three Elisp source files, cape.el, cape-char.el and cape-keyword.el, alongside a NEWS.org for the change history, a README.org in the same Org format as this description, a LICENSE and the usual .github and .gitignore. The source is written in the Org-mode documentation style, with the headers you can see in the description, which means the README and the Texinfo manual come from the same document. The package is distributed through the normal Emacs channels, with badges for GNU ELPA, GNU-devel ELPA and MELPA releases and snapshots, and the README says you can install it with package-install. The author is Daniel Mendler, and the description is titled Completion At Point Extensions with the tagline Let your completions fly. The licence is GPL-3.0, and the repository is not archived with the last push on 2026-09-27 and no GitHub releases. ## Conclusion Adopt cape.el if you use Emacs completion and want a specific source available on a key rather than only in the default completion list, for example file names or Elisp symbols in a mode where you do not want them polluting ordinary completion. Do not adopt it if you already have a completion setup that works, because each Capf added to completion-at-point-functions carries a small runtime cost and the first function returning a result wins. Before you commit, read the ordering rule in the configuration section carefully, and install it from ELPA or MELPA with package-install rather than vendoring the files. ## FAQ ### What is cape.el? It is a GPL-3.0 licensed Emacs package providing Completion At Point Extensions, so completion backends can be registered in the completion-at-point-functions list and also invoked directly from a key binding. It works alongside Corfu, Company or the default completion UI. ### How do I install cape.el? Cape is available on ELPA and on MELPA, and the README says you can install the package with package-install. The package is also available from the GNU-devel ELPA archive and from MELPA snapshots. ### Which completion backends does cape.el provide? Fourteen, including cape-abbrev, cape-dabbrev, cape-dict, cape-elisp-block, cape-elisp-symbol, cape-emoji, cape-file, cape-history, cape-keyword, cape-line, cape-rfc1345, cape-sgml and cape-tex, covering abbreviations, dictionaries, file names, history, keywords, Elisp, emoji and Unicode characters. ### Does adding a Cape backend slow down ordinary completion? Yes, a little. The README says to take care when adding Capfs to the list since each Capf adds a small runtime cost, and that Capfs occurring earlier take precedence, so the first one returning a result wins and later ones may not run. It recommends binding the commands to explicit keys instead. ## Sources - [Issues](https://github.com/minad/cape/issues) - [License: GPL-3.0](https://github.com/minad/cape/blob/main/LICENSE) - [minad/cape on GitHub](https://github.com/minad/cape) - [README](https://github.com/minad/cape/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/minad-cape