emacs-solo reaches for built-in Emacs and admits the gaps with small hacks

The pitch is zero packages, and the banner says so

The startup screen in the README is the project's own summary of itself. After the ASCII art banner it reports a loading time and a package count of zero. The configuration is described as fast, powerful and modular, and the project summary says it favours built-in functionality over third-party packages. The author's own framing is that it is a configuration used when they want to go back to the roots and challenge themselves by using Emacs with only built-in features. The size is stated too, with over 3000 lines of code, and the author argues that most of that comes from organizing things cleanly and building small reusable modules, so compared to full featured distributions it is still lean and focused. That is an unusual pitch for an Emacs configuration, because most of them are the opposite, a curated list of packages that assemble a working environment. This one treats the absence of packages as the feature and the line count as a cost you accept for keeping everything in one place.

Where built-ins stop, small hacks take over

The project states the trade honestly. The configuration favors Emacs built-ins configured in the author's own way, but when something essential is missing, such as margin git gutters, a small hacky workaround is always added. That sentence is the whole design in miniature, and it also tells you what you are signing up for. A git gutter is not an Emacs built-in, and a file that shows which lines changed is something most people consider essential in an IDE-like setup, so this configuration carries its own implementation. The screenshots the project publishes show iComplete with in-buffer completion alongside Flymake and the gutter, a help variable view, iComplete in vertical layout, Eshell, Dired with the gutter, and what the author calls a well behaved mode line. The screenshot set also shows a single init file with sections and what is described as a lot of extra mini-packages built in, which is the structural choice: mini packages that live inside the configuration rather than packages that come from elsewhere. The project also has its own themes, with Crafters, Catppuccin, GITS and Matrix named in the README.

Optional dependencies decide which features you actually get

The optional dependencies list is where the practical limits of a built-in only configuration become concrete, and it is worth reading as a feature matrix rather than as trivia. ripgrep provides quicker project grep and xref navigation, and if you opt to use regular grep instead you need to reset the customization of the grep-command variable. ghostscript is needed if you want doc-view to show documents such as PDFs. gls is the GNU implementation of ls on macOS, and on the macOS default ls you may need to change the dired-listing-switches variable. curl is only needed for uploading text or images to 0x0.st from Emacs Solo, through the emacs-solo/0x0-upload-text and emacs-solo/0x0-upload-file commands, and it is also used by emacs-solo-weather, emacs-solo-rate and emacs-solo-how-in for cheat.sh queries. wget, if present, is used by the newsticker configuration in place of the internal fetcher. mpv is needed for playing videos from news in newsticker, music from dired with the dired music player bound to C-c m, an m3u file through the m3u visualizer opened with M-x m3u-visualizer-open-buffer, online radio with C-c r, and YouTube results through emacs-solo-yt. rsync is only needed for the dired-rsync-copy command. The pattern is consistent. A feature is present in the configuration, and it becomes usable when the host program is there.

Container and GitHub CLIs are bound to keys

Two of the more useful pieces are command interfaces built on external tools rather than Emacs packages. A podman or docker container manager opens with C-c d or by running M-x container-menu with RET. A gh, the GitHub CLI, interface opens with C-c G or through M-x gh-menu with RET, and the README shows two screenshots of it in use. Neither is a rewrite of the tool, both are front ends over the binary you already have or can install. That is the pattern for the whole configuration, and it is why the optional dependencies list includes curl for the gh calls and rsync for the dired copy command. The same restraint shows up in the completion and diagnostics area, where the screenshots show iComplete, in-buffer completion, working together with Flymake rather than a lisp language server front end. The result is a configuration whose interactive surface is largely Emacs's own, with the author's preference expressed in layout, key bindings and mode line rather than in a dependency graph.

One init file, sections, and a lisp directory

The repository layout is small enough to read in full. There is init.el, an early-init.el, a lisp/ directory, a README.org and the licence file. early-init.el is the standard Emacs 27 and later split, where the code that runs before the package system loads is kept apart from the rest. The screenshots point at the second point of the structure, a single init file with sections, which is how the configuration keeps three thousand lines navigable without a package system doing the work. The README.org is the documentation format rather than a Markdown one, which is consistent with a project that treats Emacs as its own medium. The stated minimum version is the latest stable release of Emacs, which the README puts at 31.1, and the badge in the header says Emacs 31 and later. Some bleeding edge features may be tested as well, and for those you need to compile Emacs from the master branch, with the author marking those parts with an EMACS-32 tag so you can tell what you are getting into.

What you give up, and the case for reading it yourself

The honest case against this configuration is that it substitutes your own effort for a package ecosystem. There is no company behind a builtin alternative for git gutters, so the gutter is a hack, and a hack is code you inherit and maintain. The same applies to the container manager and the gh interface, which need those binaries present and behave differently across hosts, and to the macOS specific dired listing switches, which is a reminder that the configuration was written on a particular machine with a particular set of programs. If your work needs a real language server, a project management board, or a database client, none of that is coming from Emacs built-ins, and the project does not pretend otherwise. The alternative approach, if you want the same shape of environment, is to write the same configuration yourself against the same built-ins, which is what the author says he does to keep himself honest. The differentiator is therefore not the feature list but the code. You are adopting three thousand lines of Emacs Lisp written by one person, and the value of that depends entirely on whether you read it and understand it, which is exactly what the project asks you to do.

Editorial conclusion

emacs-solo suits Emacs users who want an IDE-like workflow without installing a package manager's worth of dependencies, and it suits people who enjoy reading the configuration rather than trusting a distribution. It does not suit anyone who wants a batteries-included language server setup, a project management UI, or magic that only works on one machine, because the workarounds it relies on are host specific. Before adopting it, read init.el and the lisp/ directory to see what you are adopting, confirm your Emacs is 31.1 or newer, and check which of the optional programs, ripgrep, ghostscript, curl, wget, mpv and rsync, you actually have.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. LionyxML/emacs-solo on GitHub
4. README
5. Releases