nano-emacs says it has one mandatory module, lists two, and repeats the same instruction for both

The installation says one mandatory module and the module list says two

The installation section states, in its own words, that the only mandatory module is the one that defines the faces used by other modules. The modules section then places two files under a Mandatory heading: the one that defines the fundamental colours and the one that defines the fundamental faces. Both entries carry the same instruction sentence, telling the reader that if Emacs has a theme or colour scheme loaded it must be loaded first so its colours are used. That sentence is only correct for one of them, since the other file is the thing you are being told to load before the faces. So a reader who trusts the module list installs both, and a reader who trusts the installation section installs one and finds out later. The file states the mandatory count twice and contradicts itself once.

Three variables, all read at load time with no hook to reapply them

Customisation is three variable assignments and a warning. The first sets the monospaced font family and defaults to one specific typeface; setting it to a font without proper light or bold weights is said to lose many of the key design features of the project, with no remedy offered. The second sets the proportional font and defaults to nil, meaning variable-width rendering is off until you ask for it, and naming a variable-width font is what switches on the variable-width and mixed-pitch modes. The third sets a font size that applies to most faces rather than all of them. Then the load-order note explains the catch: because of how the project is set up, these have to be set before the faces and theme functions are called, and changing one afterwards means calling both of those again by hand.

No other dependencies, except for the two modules that need packages

The requirements section is explicit that after a recent Emacs and the two fonts there are no other dependencies, which is a strong claim for a configuration project and mostly true. Two entries in the module list undercut it. One optional module configures an external completion package that the file says must have been installed by the user, with the word installed set in bold. One experimental module provides a minibuffer implementation built on another external project. Neither is loaded by default and neither is declared as a dependency, so the claim in the requirements section is accurate for the configuration as it ships while being wrong for two of its parts. The pattern is consistent with the stated philosophy of avoiding dependencies, but it means the dependency graph lives in prose rather than in a manifest.

Two fonts are required and only one of them has a documented variable

The requirements name two typefaces and say they must be installed on your system before anything else works. Customisation then exposes exactly one font variable, for the monospaced family. The second required face has no documented setting anywhere in the file, so a user who installs one typeface and not the other gets a partial result with no stated error, and a user who dislikes the second has nothing to change. That is a real gap given how central typography is to the project: the whole premise is a consistent look and feel derived from a specific set of type weights, and one of the two is hardcoded by omission rather than by choice.

The package manager snippet is fenced with a leading space in its language tag

The straight.el installation gives a snippet wrapped in a fence whose language tag is written with a space between the backticks and the word for the language. Most editors and highlighters will not recognise that tag, so the snippet renders as plain text in the file you read it in. The snippet itself registers the project as a git package from a hosting site and a repository path, with no branch, no tag and no commit pin, which means a package-manager install tracks whatever the default branch happens to hold at the moment you run it. That is a reasonable default for a configuration people are invited to copy, and it is worth knowing before you rely on a specific version of it.

Two optional modules change editor behaviour rather than appearance

Most of the module list is cosmetic, and four entries are not. The quick test loads a single file, and it does so with the user configuration suppressed:

$ emacs -q -l nano.el

That single file is marked optional in the module list, on the grounds that its content is meant to be merged into an existing configuration rather than kept, which is a slightly odd thing to make the entry point optional. The behavioural entries are elsewhere in the list. One shows a splash screen when Emacs starts. One provides what the file calls a reduced set of keybindings for a few common commands, which means loading it narrows your keymap rather than styling it. One defines a mode-dependent header line and takes care of hiding the modeline when necessary, so it interacts with a display feature you did not ask it to change. One configures Emacs so a session is carried from one run to the next. All four are in the optional group and all four are behavioural, which the file does not flag as a distinction. Given that the stated philosophy is minimal change from vanilla Emacs, the default of not loading them is the right one, and the documentation would help if it said so.

The README is generated from Org, and two modules are missing from the list

The repository holds the README in two formats, a Markdown file and an Org file, plus a second Org source and an Org file for one of the modules. That is the generator and its inputs, and it explains the formatting artefacts throughout: a link with an unclosed parenthesis in the theme module entry, a missing apostrophe in the experimental command module entry, and empty container elements where screenshots would sit. The module list in the readable portion names eighteen modules, while the tree contains two files that are not named there. The file may well list them further down; what a reader cannot do is confirm from the visible text that the list is complete, which is an odd gap for a project whose entire pitch is that you copy the parts you want.

Editorial conclusion

nano-emacs fits someone who wants a small, readable Emacs configuration they can copy module by module rather than adopt wholesale, which is exactly what the file asks you to do. Take the optional modules individually and read each one before loading it, because two of them pull in packages you have to install yourself and two others change startup behaviour or your keymap. Set the three customization variables before loading the theme functions, since there is no hook that reapplies them. And if you arrived looking for a theme, note that two of the modules named in the file are not in its own module list.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. rougier/nano-emacs on GitHub