`startup--load-user-init-file` persists its original
user-emacs-directory in a lexical binding that we cannot affect from
early-init.el, and uses it to find init.el. This prevents non-Doom
profiles' init.el files from being loaded.
A way around this is to have our own $EMACSDIR/init.el that loads
{user-emacs-directory}/init.el, but that's unnecessary work and ruins
our users' ability to use their $EMACSDIR as their $DOOMDIR, so I opted
for advice instead, to force it to recognize the changed
user-emacs-directory.
Fix: https://discourse.doomemacs.org/t/3251
If lisp/doom.el does not exist, then we assume the user isn't loading a
Doom config and fall through to $EMACSDIR/early-init.el, if it exists.
However, `load`'s NOERROR argument suppresses more than just
file-missing errors -- it suppress permissions errors and other
legitimate IO errors that I want to treat as error states, not
fall-through states. This commit fixes that.
* early-init.el (gc-cons-threshold): Set a reasonable more default for
gc-cons-threshold for non-Doom configs (16mb), instead of
most-positive-fixnum, which would eventually cause
freezing/stuttering for non-Doom profiles.
If early-init.el is loaded by another doomscript that uses
--init-directory or --profile for its own purposes, then they could
unintentionally alter user-emacs-directory. Lets only respect the
envvars in noninteractive sessions.
- Adds $DOOMPROFILELOADFILE: Controls where to read and write the
profile loader. Changing this may be helpful for users on nix/guix,
who have deployed Doom to a read-only location. This sets
`doom-profile-load-file`.
- Changed profile load file's default location (used to be
$EMACSDIR/profiles/init.el, is now $EMACSDIR/profiles/load.el). The
gitignore was updated to reflect this.
- Adds $DOOMPROFILELOADPATH: A colon-delimited list of profile config
files and directories (semi-colon on Windows) which dictate what Doom
reads in order to discover your profiles. Config files are required to
have an *.el extension. This sets `doom-profile-load-path`.
- Changes the nomenclature around this loader script. I used to refer to
it as the profile bootstrapper. I'll now refer to it as the profile
load file, and I've renamed `doom-profiles-bootstrap-file` to
`doom-profile-load-file` to reflect this.
- The variables `doom-profile-dirs` and `doom-profile-config-files` were
merged into doom-profile-load-path.
- Both envvars have also been documented in `doom help` (and
$DOOMPROFILE's has been updated).
Ref: #6794
- Swap out the funcall+alist lookup for a pcase (which is expanded to a
cond, which is is faster and easier to read).
- Wrap bootstrap file to $EMACSDIR/profiles/init.el, but byte-compile it
to $EMACSDIR/profiles/init.X.el where X is emacs-major-version.
- Make doom-profiles-save's second argument optional (defaults to
doom-profiles-bootstrap-file).
- Make doom-profiles-save throw a error if byte-compilation fails for
some reason.
- Rename the tempvars to include 'doom' in their name, so debuggers know
where they originate.
I misunderstood the issue in 1081588. `user-emacs-directory` is never
nil, even in batch sessions. Instead, it is simply set to the wrong path
in cases where Doom is deployed to a non-standard location. It's needed
to change it there, but never in interactive sessions.
Fix: #6777
Amend: 108158876c
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
