Add a Home Manager module

It turns out using Home Manager's `programs.emacs` module does not work
correctly. Document that in HACKING.md for future reference.
This commit is contained in:
Marien Zwart 2024-04-29 14:58:41 +10:00
parent 7848f69115
commit b3ed7ea627
No known key found for this signature in database
4 changed files with 215 additions and 5 deletions

View file

@ -53,3 +53,37 @@ module live in the Nix store is the least bad option.
This does break things that write to DOOMDIR at runtime. `custom-file` is an
obvious example, but there are probably a few more.
## `programs.emacs.package` / nesting emacsWithPackages
Home Manager's `programs.emacs` wraps its Emacs package with emacsWithPackages.
We don't work as an input to emacsWithPackages.
First bug: emacsWithPackages writes a site-start that loads
`$emacs/share/site-lisp/site-start` first. That is: it assumes the emacs package
it wraps has its own site-start. That's true if it's an actual emacs but at
first glance might also break if it's another emacsWithPackages, because its
site-start goes in a separate `emacs-packages-deps` derivation (I didn't test
this further).
We could fix that (by adding a trivial site-start.el of our own), but there's a
second bug: when Doom loads its profile, it overwrites `load-path`. This defeats
the purpose of having that outer emacsWithPackages in the first place.
During normal interactive startup, the second bug masks the first: site-start
gets loaded from the Doom profile's load path, skipping the outer
emacsWithPackages entirely. So at first glance the Home Manager `programs.emacs`
module will seem to work...
During non-interactive startup, the first bug surfaces. The easiest way of
triggering this is `doom` cli, which fails with:
```
Unexpected error in Dooms core: "/nix/store/3hr4amd670vbf5h1w1jw18y3a9hv1689-source/lisp/doom-cli.el", (file-missing "Cannot open load file" "No such file or directory" "/nix/store/7vvp8axf8h4qrx7mj3mh1dsxj80393k2-emacs-pgtk-with-doom-29.3/share/emacs/site-lisp/site-start")
```
Setting DEBUG=1 makes it more obvious where this fails (doom-cli.el loads
site-start).
Non-interactive use of emacs also seems to trigger this: in particular it breaks
flycheck of elisp code with a similar error message about site-start.