Emacs auto-complete ranks candidates with usage statistics, and wants a new maintainer

The differentiator is a per source score, not a candidate algorithm

Plenty of Emacs packages can turn a prefix into a list. What this one claims, in its own words, is reducing completion overhead by using a statistic method. Concretely, the ranking is per source: once you have accepted an lisp symbol over a buffer word more often, that preference changes the order next time. The candidate set is not the innovation here, the ordering is.

The package describes itself as an extension of the standard Emacs completion interface rather than a replacement, which matters for how it composes with the rest of a config. Sources register themselves, and the extension presents the merged list through a visual interface so you can see what is on offer before you accept anything.

Screenshots in the repository show three labelled examples: auto completion, fuzzy completion, and incremental search. The README also says that fuzzy-el and popup-el are looking for new maintainers.

Install from MELPA, then one form of config

The package is on MELPA and on MELPA-STABLE, so it is an ordinary MELPA package rather than a file you vendor into your config. Installing it is an interactive call:

M-x package-install [RET] auto-complete [RET]

Enabling it is a single call to the default configuration, which sets up the standard sources and the extension hooks:

(ac-config-default)

That is genuinely the whole documented setup. The README has no third step, no key binding advice and no per-source configuration section; anything beyond that is in doc/manual.md, which the README links rather than restates. Nothing in the README says whether loading auto-complete requires a `require` line in your init file or whether ac-config-default is the only entry point, so check the manual if you are composing this with a literate config.

Eask drives the build, not a hand written test runner

The Makefile is worth reading because it tells you what the project's own idea of a build is. The version string is not stored anywhere, it is extracted from the source file with a one line perl invocation reading the `;; Version:` header out of auto-complete.el. From there, the package name is derived.

Every stage is delegated to Eask. Compiling is `$(EASK) compile`, packaging and installing is `$(EASK) package` followed by `$(EASK) install`, and cleaning is `$(EASK) clean all`. The CI target is `ci: compile install test`, and the test target installs development dependencies and then runs ert against a single entry point:

$(EASK) test ert ./tests/run-test.el

One test entry point for the whole package is thin, and it lines up with a todo item in the README that reads test facility, still unchecked. The repository does have a tests/ directory, so tests exist, just not the broader facility the author has in mind.

Two other targets exist for people who want the docs site. README.html is generated from README.md with pandoc using the standalone HTML writer, and the site target builds doc/ and copies images into the separate ../auto-complete.github.com checkout.

The README todo list is the honest status report

Most projects hide their gaps. This one publishes them. The unchecked entries include etags and ctags support, EmacsWiki support, a test facility, composed character support, minibuffer completion, an explicit performance and cache issue, asynchronous processing, and kanji conversion support.

The list does not explain the scope or current behaviour of these items, so they should be treated as open work rather than detailed diagnoses of the existing implementation.

There is also a narrower entry, quick help positioning on tabs, marked as a bug.

Maintenance state: not archived, but asking for a maintainer

The repository is not archived and the last push was on 2026-06-19. There are no GitHub releases at all, so version tracking goes through the header in auto-complete.el and a CHANGELOG.md in the repository.

The significant fact is in the README's own callout at the top: auto-complete, popup-el and fuzzy-el are all looking for new maintainers, with the request directed at issue 509. This is a maintenance warning worth considering before adopting any of the three projects.

The licence is GPLv3, with COPYING.GPLv3 and COPYING.FDL both in the repository. That matters more than usual in Emacs, because package ecosystems there are built on GPL compatibility.

Against company-mode, corfu and the built in completion

The alternative worth comparing is corfu, a modern completion system for Emacs 28 and later that is lighter and depends on no companion display package. If you already have a recent Emacs and corfu installed, adding auto-complete and popup-el and fuzzy-el on top is three packages to learn for a ranking feature you can get elsewhere.

The built in `completion-at-point` plus `complete-any` is the zero dependency baseline. It has no ranking, no popup to navigate visually, and it works out of the box, which is a real advantage when you are debugging and do not want a third party layer deciding what you see.

What auto-complete offers over all three is the statistical ordering learned from your own history, and the source abstraction where a source is anything registering candidates. If your completion is noisy because sources return too many candidates, ranking is the feature that fixes it. If your problem is that completion does not exist yet, this is the wrong package.

Note the comparison is not quite fair on Lisp performance, because the todo list explicitly still names a cache issue and the lack of async processing.

Editorial conclusion

Before adopting auto-complete, read its maintainer notice and unchecked todo entries, then consult the linked user manual for details not included in the README. If you proceed, install it from MELPA and run the documented default configuration.

Frequently asked questions

Official sources

1. auto-complete/auto-complete on GitHub
2. Issues
3. Project website
4. README