format-all gives Emacs one formatting command for every language in the buffer

The problem is one command per language, and that is the thing being removed

The package states its purpose plainly. It lets you auto-format source code in many languages using the same command for all languages, instead of learning a different Emacs package and formatting command for each language. That is a real friction point in a polyglot editor, because the usual answer in Emacs is one major mode per language with its own keybinding for its own formatter, and those keybindings do not line up. The interaction here is a single interactive command, M-x format-all-region-or-buffer, which the README says will try its best to do the right thing, and a minor mode, format-all-mode, for auto-formatting on save, with the documentation of that function holding the instructions. The phrase try its best is a warning as much as a description, since the package is working out the language of the buffer and then finding a tool to run, and the two steps can each be wrong.

The language list is really a list of external tools

The longest part of the README is the supported languages section, and reading it tells you the architecture. Each entry names a language and then the formatter or formatters it can use, which are almost always programs you install separately. The Python entry, for instance, lists black, isort, ruff format and yapf, and the Go entry lists gofmt and goimports:

* **Python** ([*black*](https://github.com/ambv/black), [*isort*](https://github.com/PyCQA/isort), [*ruff format*](https://docs.astral.sh/ruff/formatter/), [*yapf*](https://github.com/google/yapf))
* **Go** ([*gofmt*](https://golang.org/cmd/gofmt/), [*goimports*](https://godoc.org/golang.org/x/tools/cmd/goimports))

The rest of the table follows the same pattern across dozens of languages, from Angular with prettier to C and Objective-C with clang-format and astyle, Haskell with a choice of brittany, fourmolu, hindent, ormolu and stylish-haskell, Nix with nixpkgs-fmt, nixfmt and alejandra, and LaTeX with latexindent and auctex. Some languages are handled by Emacs itself, such as Emacs Lisp, BibTeX and Hy. The implication for an adopter is that the package is a dispatcher with a configurable table, and the table can only be as good as the tools present on the machine running it.

Maintenance pace is stated in the README, which is unusual and useful

The note at the top of the README is the most honest paragraph in the file. It says the package is actively maintained but that, due to lack of time, complex tasks are done at a slow pace, while simple tasks like adding or fixing formatter definitions are often done immediately, and that for faster progress additional maintainers are welcome. That single note calibrates expectations for anyone about to file an issue. If you want a new language mapped, you are in the fast lane, because that is the category the maintainer describes as handled straight away. If you want a redesign of how the dispatcher selects a formatter, or a change to the mode behaviour, you are in the slow lane, and the note invites a second maintainer rather than promising a date. The repository was last pushed on 2026-06-20, so the table of languages is a moving target and the README is the place to check it.

MELPA is the distribution channel, and there are no tagged releases

The package is published through MELPA, with the homepage pointing at the package listing on melpa.org, which is how Emacs users normally install packages that are not bundled with the editor. The repository itself is small. The top level holds format-all.el, the package source, an admin directory, the README, the LICENSE, a .github directory and a .gitignore. There are no GitHub releases, so the version you get is the one MELPA serves, and the change history is the commit log rather than a release feed. That arrangement is normal for an Emacs package of this size, and it also means that a specific commit in the repository is the only way to pin an exact state, which matters if you depend on a particular formatter mapping that has not yet reached MELPA.

Where the package stops and your project policy starts

The limitation to plan around is that format-all does not own the formatting decision, it only makes the call. Which formatter runs for a given language, and with which options, comes from the mapping in the package and from the configuration of the tool it runs, and the README does not document a per project configuration mechanism. So if your team has already decided that Python is formatted with black at a particular line length, or that Go is formatted with goimports rather than gofmt, that decision lives in your own editor setup and in your project files, and this package does not enforce it. It is also not a replacement for a pre-commit hook or a build target, because it acts on the buffer in front of you rather than on a tree of files. And the tools have to exist. A language listed in the table whose binary is not on your path will not format, and the failure will look like the command doing nothing rather than like an error about a missing program.

The alternative is letting the project format the tree

The realistic alternative is to let the project define the formatting command and run it over the tree, either from a make target or from a pre-commit hook, and to keep the editor out of it. The difference in approach is scope and timing. The project side is authoritative, because it is the same command in CI and on a developer machine, and it formats files that nobody opened, which matters for a pull request that touches a hundred files. The editor side is the opposite. It formats what you are looking at, it gives you the result immediately, and it costs nothing to run because the tools are already on your path, but it formats only what you happened to visit, and it can disagree with the project configuration. Teams that already have a pre-commit hook usually keep it and gain nothing from format-all. People whose projects have no formatting policy at all, and who work across languages, get the most out of it.

Editorial conclusion

Adopt format-all if you work in Emacs across several languages and want one binding that formats whatever is in the buffer, since the language detection and the command mapping are the part you would otherwise rewrite. Do not adopt it if your project already defines formatting through a build file or a pre-commit hook, because this package dispatches to whatever formatter you have installed rather than owning that policy, and it will not install the tools for you. Before you rely on it, check which formatter binaries are on your path for the languages you actually write, and read the note about the project's pace, because the mapping table grows faster than the rest of the package.

Frequently asked questions

Official sources

1. Issues
2. lassik/emacs-format-all-the-code on GitHub
3. License: MIT
4. Project website
5. README