user-emacs-directory is nil in batch sessions, which early-init.el
wasn't expecting, which caused bin/doom to refuse to run out of a
non-standard location.
Fix: #6777
This setting (along with load-file-rep-suffixes) is simplified at
startup to optimize file IO at startup, but it was supposed to be undone
at the end of doom-start (in doom-before-init-hook). Unfortunately, the
restoration hook was not reaching their top-level bindings, causing
dynamic modules (like vterm-modules.so) to fail to load.
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.
I move our hackiest and least offensive startup optimizations to core,
so they're easy for me to keep track of (they'll likely change often,
between major Emacs releases), to keep them from affecting non-Doom
profiles, and make it easy for readers to use as a reference.
This centralizes Doom's core startup optimizations and, as a
side-effect, reduces the runtime of bin/doom commands substantially.
This also simplifies the user story for loading Doom remotely (for batch
sessions or doomscripts).
If an error occurs before this is restored, this can leave Emacs in a
state where it appears frozen and won't redraw. This can be overcome by
hooking into the debugger, but I'll try that another day.
BREAKING CHANGE: This restructures the project in preparation for Doom
to be split into two repos. Users that have reconfigured Doom's CLI
stand a good chance of seeing breakage, especially if they've referred
to any core-* feature, e.g.
(after! core-cli-ci ...)
To fix it, simply s/core-/doom-/, i.e.
(after! doom-cli-ci ...)
What this commit specifically changes is:
- Renames all core features from core-* to doom-*
- Moves core/core-* -> lisp/doom-*
- Moves core/autoloads/* -> lisp/lib/*
- Moves core/templates -> templates/
Ref: #4273
- Fixes Doom's former inability to (trivially) juggle multiple profiles
based on the same EMACSDIR (see #6593).
- Adds '--profile NAME' switch to bin/doom (also recognized
$DOOMPROFILE).
- Adds new doom-profile* variables. These will eventually replace
doom-{local,etc,cache}-dir and doom-{autoloads,env}-file.
This is intentionally messy to ensure backwards compatibility for a
little while longer. This will be fixed over the next couple weeks.
Ref: #6593
Formerly, profiles.el and $EMACSDIR/profiles/* were mutually exclusive.
I.e. if the file existed, it'd never check the directory. Now, it will
check the directory if the requested profile isn't in profiles.el, or
the file didn't exist.
Amend: 5b6b204bcb
This allows users to use Doom core to switch between Emacs configs (they
don't have to be Doom configs either). Taking after Chemacs, these
configs (called "profiles") can be declared in $EMACSDIR/profiles.el or
implicitly as directories under $EMACSDIR/profiles/ (symlinks work too).
Launch a profile with `emacs --profile foo` or by setting $DOOMPROFILE:
`DOOMPROFILE=foo emacs`.
An example profiles.el looks like this:
((doomemacs (user-emacs-directory . "~/.config/emacs")
(env ("DOOMDIR" . "~/.config/doom")))
(spacemacs (user-emacs-directory . "~/.config/spacemacs"))
(prelude (user-emacs-directory . "~/.config/prelude"))
(altdoom (user-emacs-directory . "~/.config/doomemacs")
(env ("DOOMDIR" . "~/.config/doomprivate1")))
(altdoom2 (user-emacs-directory . "~/.config/doomemacs")
(env ("DOOMDIR" . "~/.config/doomprivate2"))))
Chemacs users will find the format of this file familiar; the biggest
differences are:
- Keys are symbols, not strings
- There is no, special "default" profile. The fallback profile is the
Doom Emacs config doing the bootloading, living in ~/.config/emacs or
~/.emacs.d. If you don't like that, set $DOOMPROFILE in your dotfiles
to the name of another profile.
WARNING: bin/doom does not understand --profile or $DOOMPROFILE yet. To
sync a particular profile, you'll have to run its bin/doom directly,
e.g.
To sync the "global" doom:
~/.config/emacs/bin/doom sync
To sync your "altdoom" (and "altdoom2") profiles:
~/.config/doomemacs/bin/doom sync
--init-directory was added in Emacs 29. This backports it for 27/28
users, so users can trivially load an Emacs config living in another
directory (will be necessary for future versions of Doom's sandbox).
However, for this to work, Doom needs to live in ~/.emacs.d or
~/.config/emacs.
Ref: emacs-mirror/emacs@8eaf04de83
Restructures Doom's primary core files and entry points to prepare for
backports (from the new CLI) coming soon.
- Removes $EMACSDIR/init.el.
- Doom configures Emacs to ignore ~/.emacs and ~/_emacs files.
- Doom's bootstrapper for interactive sessions was moved out of core.el
and doom-initialize into doom-start.el. This change is preparation for
Doom's new profile system (coming soon™️), where this bootstrapper
will be dynamically generated.
- core.el and early-init.el have been reorganized, comment headers moved
around, and comments updated to reflect these changes.
A mistake that snuck into 55c1cac while backporting some code from the
CLI rewrite. It was harmless and likely had no side effects, however.
Amend: 55c1cac43f
Unnecessary redraws can add 0.2-0.4s to startup times in some cases,
especially where site-files are involved (which spam *Messages* with
"Loading X..." messages; which force redraws).
May also indirectly fix#5643 by deferring redisplay (and therefore
window-buffer-change-functions, which triggers doom-init-ui-hook, which
triggers both Doom's dashboard and persp-mode).
Also removes a redundant set-language-environment call.
Ref #5643
The two doom-gc-* variables in init.el couples the rest of the config to
these two files. The bulk of GC/file-handler optimization was moved into
core.el and simplified (all that idle-timer voodoo was overkill).
Also adds (setq frame-inhibit-implied-reize t) to early-init, which
speeds up startup a fair bit in some edge cases with larger fonts.
squash! Simplify and decouple init files
In the interest of DRY-ness, I avoid redefining `doom-gc-cons-upper-limit`. This value is likely to diverge from the default value of `doom-gc-cons-upper-limit` in the future anyway.
