Bootstrapping doom with an literate configuration

[ispringle]

What did you expect to happen?

I expected that on a clean install of doom (ie doom install && doom sync with a "fresh" ~/.emacs.d/) the literate config in $DOOMDIR would be seen, tangled, and then used -- if not in the doom install at least in the doom sync.

What actually happened?

When I ran doom install it created new config files (init.el, config.el, packages.el) and used those as my config. Then on running doom sync the literate config was ignored.

Describe your attempts to resolve the issue

I was able to "bootstrap" the literate config by modifying the stock init.el. I added :config literate and then reran doom sync (actually did a SPC-h-r-r).

Steps to reproduce

1. Clean slate (either a new computer with no ~/.emacs.d/ or run rm -rf ~/.emacs.d
2. Clone Doom EMacs
3. doom install
4. doom sync
5. emacs
6. Be surprised by your missing configuration.

System Information

https://pastebin.com/jCnJRwCA

[elken]

Because of the complexity, the default behaviour is to not use a literate configuration and instead to let the user opt-in to using one.

You've not specified exactly if you have an empty $DOOMDIR or not, and in that case having done it many times I can say that a populated $DOOMDIR followed by doom sync does work to bootstrap.

[ispringle]

Yes, I didn't clarify, was just sorta running on the assumption... but yes, I did have a $DOOMDIR which contained my config.org file, as well as a few other files (assets for splashpage and few .el files that I think my literate config generated but I am unsure about 😂). In this particular case, I had just nuked my ~/.emacs.d and then reinstalled Doom (total accident, not because of any problems).

[elken]

I see, well best guess would be doom install creates the files it expects which means the literate setup is ignored.

If you nuke ~/.emacs.d and re-install doom and just do doom sync does that work?

[hlissner]

As elken said, doom install is more for first-time deployment (when the user has no config) of a standard config, and should be avoided if you already have a config.

That said, it could do more to detect a pre-existing (and literate) config. I'll incorporate that into the upcoming v3.0 release, but v3.0 will also do you one better: first-class support for literate configs. This will detect and tangle any/all of $DOOMDIR/{init,config,cli,profiles,packages}.org. This happens early enough in the doom sync/doom install process that folks will be able to bootstrap all Doom's config files with a literate config. This was formerly impossible because Doom got its literate support from one of its modules, which required a $DOOMDIR/init.el and doom! block with :config literate uncommented to exist to activate it. Catch 22.

In any case, I'll leave this open until this is done (and I'll link to #4273 in the meantime).