Skip to main content

init.el

init.el is deliberately tiny. Its only jobs are:
  1. Register MELPA and NonGNU ELPA as fallback archives for anything Nix does not ship.
  2. Put lisp/ on the load-path.
  3. Point custom-file at var/custom.el so M-x customize has somewhere to scribble.
  4. require each module in the right order. Archive refresh is not on the startup path — there is no background warm-up at all; archives are fetched only on demand.
Everything else — GC, encoding, theme, modeline, keybindings, package configuration — lives in early-init.el or one of the lisp/init-*.el modules.

Package archives

Nix provides most packages via load-path, so use-package finds them without touching the network. The archives above only come into play for packages that Nix does not ship. Registering an archive performs no I/O, and nothing in the config refreshes the archive index at launch. A download happens only when it is actually needed:
  • package-install — including the :ensure t path — calls package--archives-initialize, which reads the on-disk cache under elpa/archives/ and downloads only when that cache is empty.
  • M-x package-refresh-contents and M-x list-packages refresh when you ask them to.
So a fresh Nix deployment, where every :ensured package is already on load-path, starts up without contacting MELPA at all.

Load path

Custom file

custom.el is write-only: Jotain never loads it back. The declarative config in git remains the single source of truth; the file exists only so M-x customize has somewhere to scribble without touching init.el.

Module loading

init.el then requires each module in order. See Modules for what each file owns and the full load order.
Last modified on August 23, 2026