BREAKING CHANGE: This commit makes three breaking changes: - Doom now fully and dynamically generates (and byte-compiles) your profile and its init files, which includes your autoloads, loading your init files and modules, and then some. This replaces doom-initialize-modules, doom-initialize-core-modules, and doom-module-loader, which have been removed. This has also improved startup time by a bit, but if you use these functions in your CLIs, for instance, this will be a breaking change. - `doom sync` is now required for Doom to see your profiles (and must be run whenever you change them, or when you up/downgrade Emacs across major versions). - $DOOMDIR/init.el is now read much earlier than it used to be. Before any of doom-{ui,keybinds,editor,projects}, before any autoloads are loaded, and before your load-path has been populated with your packages. It now runs in the context of early-init.el, giving users freer range over what they can affect, but a more minimalistic environment to do it in. If you must have some logic run when all that is set up, add it to one of the module hooks added in e08f68b or 283308a. This also poses a significant change to Doom's load order (see the commentary change in lib/doom.el), along with the following (non breaking) changes: 1. Adds a new `doom profiles sync` command. This will forcibly resync your profiles, while `doom sync` will only do so if your profiles have changed. 2. Doom now fully and dynamically generates (and byte-compiles) your user-init-file, which includes loading all your init files, modules, and custom-file. This replaces the job of doom-initialize-modules, doom-initialize-core-modules, and doom-module-loader, which have been removed. This has also improved startup time by a bit. 3. Defines new doom-state-dir variable, though not used yet (saving that and the other breaking changes for the 3.0 release). 4. Redesigns profile directory variables (doom-profile-*-dir) to prepare for future XDG-compliance. 5. Removed unused/unimportant profile variables in doom.el. 6. Added lisp/doom-profiles.el. It's hardly feature complete, but it's enough to power the system as it is now. 7. Updates the "load order" commentary in doom.el to reflect these changes. |
||
---|---|---|
.. | ||
safe-mode | ||
README.org |
Doom's profile directory
- Introduction
- How use profiles
- Auto-generated profiles
- Fallback profile
- Gotchas
- How to switch from Chemacs
- But Doom is kinda heavy to be a bootloader…
Introduction
In order to power Doom's soon-to-be generational package manager, I wrote a profile system. This system can effectively replace Chemacs; permitting you to switch between multiple Emacs configs on-demand (and those configs don't have to be Doom configs).
While I work on the formal documentation for this system, I've created this
brief guide to walk users through their use. However, for this to work, Doom
must live in ~/.emacs.d
or ~/.config/emacs
. I'll refer to this as
$EMACSDIR
(and your private Doom config, in ~/.doom.d
or ~/.config/doom
,
as $DOOMDIR
).
How use profiles
-
Declare all your profiles in either:
-
One or multiple profile files at:
$DOOMDIR/profiles.el
$EMACSDIR/profiles.el
~/.config/doom-profiles.el
~/.doom-profiles.el
-
Or an implicit profile, which are inferred from the sub-directories of:
$DOOMDIR/profiles/
$EMACSDIR/profiles/
Implicit profiles may have a
.doomprofile
file to apply additional settings. Example .doomprofile.
-
- To run
$ doom sync
whenever you change the above, to regenerate Doom's cached profile loader (generated at$EMACSDIR/profiles/init.X.elc
, where X is your major Emacs version).
-
To launch them:
- Launch the profile you want:
$ emacs --profile FOO
- Use
bin/doom
on the profile you want:$ doom sync --profile FOO
- Launch the profile you want:
Auto-generated profiles
Doom v3's sandbox and transactional package manager are capable of generating profiles on-the-fly. The former for rapid, isolated testing, and the latter for rollback/snapshot traversal for disaster recovery purposes.
These auto-generated profiles will be stored and versioned in:
$XDG_DATA_HOME/doom/$PROFILE_NAME/@/$PROFILE_VERSION/
Fallback profile
Unlike Chemacs, Doom's profiles has no notion of a "default"/fallback profile.
The fallback profile is the Doom installation doing the bootloading. This
"global" profile is unique in that it won't respect a .doomprofile
– in other
words, it's not treated as a normal profile.
It is this way so that the profiles system imposes no overhead on users that aren't interested in the profile system (or prefer to use Chemacs).
However, you can emulate this behavior by registering the "global" profile as a
profile, and setting $DOOMPROFILE
or aliasing emacs
, like so:
;; in a profiles.el file
((default)
...)
# in .zshrc or .bash_profile
export DOOMPROFILE=default
# Or
alias emacs='emacs --profile default'
Gotchas
There are two caveats with this profile system:
- It requires that Doom live in
~/.config/emacs
or~/.emacs.d
. A non-standard install location won't work, unless you use Emacs 29's new--init-directory DIR
switch and launch Emacs withemacs --init-directory ~/nonstandard/emacs.d --profile NAME
.bin/doom
is fine with it, though. -
The profile system can be storage-inefficient. A barebones Doom config averages at ~1mb without installed packages and ~3.75mb with (straight alone is 2.6m). A fully-fledged Doom config can average 500mb-1.4gb; the majority of which are packages, but include server binaries, elisp+native bytecode, and caches add up too.
To mitigate this, Doom dedups packages across snapshots of a single profile (e.g.
profile@23
->profile@24
), but it cannot (yet) do this across profiles (e.g. ifprofile1
andprofile2
both installorg
). Even then, packages whose recipes change (either locally or upstream) may dodge this deduplication and get cloned anew (to ensure historical integrity) – though this shouldn't happen often, but can build up over time.So v3 will introduce a
doom gc
command, which offers a couple nix.gc-esque switches to control it. E.g.-
Acts on the "global" profile:
doom gc --older-than 21d
doom gc --keep 10
-
Act on a specific profile:
doom gc --profile foo ...
-
Act on all known profiles
doom gc --profiles '*' ...
Users can change defaults from their
init.el
orcli.el
, or configuredoom sync
to auto-GC by whatever rules they like. And the good doctor will warn you if you haven't GCed in a while, or you're in excess of some threshold (which I haven't decided yet). -
How to switch from Chemacs
- Delete Chemacs from
$EMACSDIR
. - Install Doom there:
$ git clone https://github.com/doomemacs/doomemacs ~/.config/emacs
-
Move
~/.emacs-profiles.el
to~/.config/doom/profiles.el
and transform the string keys to symbols and adaptenv
entries like so:;; ~/.emacs-profiles.el (("default" (user-emacs-directory . "~/.emacs.default") (env ("DOOMDIR" . "~/.doom.private"))) ("spacemacs" (user-emacs-directory . "~/spacemacs")) ("prelude" (user-emacs-directory . "~/prelude"))) ;; ~/.config/emacs/profiles.el ((default (user-emacs-directory . "~/.emacs.default") ("DOOMDIR" . "~/.doom.private")) (spacemacs (user-emacs-directory . "~/spacemacs")) (prelude (user-emacs-directory . "~/prelude")))
A comprehensive example of Doom's profiles.el file can be found in docs/examples.org.
Differences with Chemacs profiles:
- Keys are symbols, not strings.
- Doom's profiles.el has a syntax for evaluating code, expanding paths, and appending/prepending to variables (with deferral). See the examples.org link above.
- Doom's profile system won't install Straight.el for you.
- Doom does not have a special "default" profile. If you don't specify a
–profile, it will simply start up the Doom config living in
~/.config/emacs
. See the "Fallback profile" section below for a workaround.
- Then launch a profile. E.g.
$ emacs --profile prelude
.
But Doom is kinda heavy to be a bootloader…
I agree! To remedy that, I'll soon split Doom up into three projects: its core (where its bootloader lives), its official modules, and its community contributed modules. At that point, Doom will be much lighter!