A mistake in 5a5195b caused modules without an explicit :depth to be
loaded in the wrong order (because their final depth wasn't cached
correctly, and so were all given a depth of 0, thus falling back on
their insertion order, which is precisely what 5a5195b was trying to
fix). This commit fixes that and changes the module cache vectors to
match the structure of doom-module-context, for consistency.
Amend: 5a5195b84dFix: #6813Fix: #6859
Where f9201eb introduced a general context system, this one introduces
one for modules, to simplify our let-bind game when interacting with
modules, and to more efficiently expose module state to modulep! (which
gets called at runtime a great deal, so its performance is important).
* lisp/doom-lib.el (doom-log): simplify macro and introduce
doom-inhibit-log variable.
* lisp/doom-modules.el (modulep!): fix reported file path if modulep!
fails to find the local module.
* lisp/lib/debug.el (doom-debug-variables): disable doom-inhibit-log
when debug mode is on.
Ref: f9201eb218
- Adds doom-module-packages-file and doom-module-metadata-file.
- Uses them and the other doom-module-*-file variables where they were
previously hardcoded.
- Add .el extension to doom-module-{init,config}-file; it is now the
consumer's responsibility to strip/change/keep the extension as they
see fit.
I intend to phase out the internal usage of use-package in Doom's core
and modules. The macro is too complex and magical for our needs.
That said, until we've fully removed it, this :config use-package is
hardcoded to be enabled-by-default, until use-package has been
refactored out of core and modules. It'd be wise not to add it to your
doom! blocks yet.
This introduces a depth field for modules so that they may dictate their
load order explicitly, it also treats depths <= -100 or >= 100 as
special depths, which will be loaded early, before their respective
doom-{before,after}-module-{init,config}-hook. This permits psuedo
modules like :core and :user modules to be treated as normal modules
without too many special cases.
This also fixes a module load order issue on Emacs 29 (#6813), caused by
emacs-mirror/emacs@4311bd0bd7, which changed the return value order of
hash-table-{keys,values} causing modules to be loaded in reverse order;
resulting in the loss of evil keybinds, among other things.
Other notable changes:
- Changes the data structure for module data caches from a list to a
vector. Uses less memory and permits faster lookups. Also adds two
depth fields to the front of it.
- Changes the signature of doom-module-list and doom-package-list.
- Renames doom--read-packages -> doom-packages--read for consistency
with naming convention.
- Add doom-module-depth function.
- Adds a temporary doom-core-dir/init.el file, which is responsible for
loading doom-*.el.
Fix: #6813
Ref: emacs-mirror/emacs@4311bd0bd7
The doom-modules table should reflect the user's intentions, not the
actual state of its modules (e.g. by omitting modules that couldn't be
found at activation time).
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.
BREAKING CHANGE: For consistency and correctness, I've renamed the
module init/config hooks, and added new ones:
- Adds doom-before-modules-config-hook
- Adds doom-after-modules-config-hook (replaced doom-before-init-modules-hook)
- Adds doom-before-modules-init-hook
- Adds doom-after-modules-init-hook (replaced doom-init-modules-hook)
- Removed doom-after-init-modules-hook (replaced w/ after-init-hook)
The old naming (and timing) was counterintuitive. Now, it's named after
the loaded file group (init.el vs config.el), and I added before/after
variants. Altogether, this should make them less ambiguous.
I've also moved some functions in various modules to more correct hooks.
Load order before this change:
- $EMACSDIR/early-init.el
- $EMACSDIR/lisp/doom.el
- $EMACSDIR/lisp/doom-start.el
- $DOOMDIR/init.el
- {$DOOMDIR,~/.emacs.d}/modules/*/*/init.el
- `doom-before-init-modules-hook'
- {$DOOMDIR,~/.emacs.d}/modules/*/*/config.el
- `doom-init-modules-hook'
- $DOOMDIR/config.el
- `doom-after-init-modules-hook'
- `after-init-hook'
- `emacs-startup-hook'
- `window-setup-hook'
Load order after this change:
- $EMACSDIR/early-init.el
- $EMACSDIR/lisp/doom.el
- $EMACSDIR/lisp/doom-start.el
- $DOOMDIR/init.el
- `doom-before-modules-init-hook'
- {$DOOMDIR,~/.emacs.d}/modules/*/*/init.el
- `doom-after-modules-init-hook'
- `doom-before-modules-config-hook'
- {$DOOMDIR,~/.emacs.d}/modules/*/*/config.el
- `doom-after-modules-config-hook'
- $DOOMDIR/config.el
- `after-init-hook'
- `emacs-startup-hook'
- `window-setup-hook'
...that are always enabled. This way, the module API treats them as any
other module.
This also changes doom-module-load-path. If supplied directories,
doom-user-dir will not be the CAR of its return value. If no dirs are
supplied, then doom-core-dir and doom-user-dir are included (and will
always be the first two items in the returned list).
For small amounts of data, symbol plists are the most efficient (space
and time wise) as data access gets in Emacs. Hash tables, though O(1),
impose a minimum threshold of overhead before it becomes the efficient
option, but this benefit won't be obvious for datasets of at least 60 or
less.
Since modulep! is used *a lot*, and used to determine a module's
state (and state of its flags), there is a benefit to caching it.
Still, this is only a read-only cache, and does not replace the
`doom-modules` hash-table, which will always be the preferred interface
for the rest of the module API.
Used to return the hash-table `doom-modules` (if not all-p), but I've
changed it to return a list of cons cells (:CATEGORY . MODULE),
representing all enabled modules, in the order they were enabled.
The purpose of this change is to prepare for a change in the structure
of doom-modules, and how Doom stores its module metadata.
- Rename doom-module-path -> doom-module-expand-path, to better reflect
its purpose.
- Optimize doom-module-locate-path to try caches and
locate-file-internal, before looping through doom-modules-dirs.
- Rely on file-name-concat to join paths, rather than string
concatenation. file-name-concat is more robust for the purpose and
has lower overhead than expand-file-name.
This was removed upstream, and while we haven't bumped use-package for
this to affect us, I may as well remove it early.
Doom will be dropping use-package from core in 3.0, in any case.
Fix: #6699
Ref: 8a3d29e433
- Deprecates the doom-private-dir variable in favor of doom-user-dir.
- Renames the pseudo category for the user's module: :private -> :user.
- Renames the doom-private-error error type to doom-user-error.
Emacs uses the term "user" to refer to the "things" in user space (e.g.
user-init-file, user-emacs-directory, user-mail-address, xdg-user-dirs,
package-user-dir, etc), and I'd like to be consistent with that. It also
has the nice side-effect of being slightly shorter. I also hope
'doom-user-error' will be less obtuse to beginners than
'doom-private-error'.
featurep! will be renamed modulep! in the future, so it's been
deprecated. They have identical interfaces, and can be replaced without
issue.
featurep! was never quite the right name for this macro. It implied that
it had some connection to featurep, which it doesn't (only that it was
similar in purpose; still, Doom modules are not features). To undo such
implications and be consistent with its namespace (and since we're
heading into a storm of breaking changes with the v3 release anyway),
now was the best opportunity to begin the transition.
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
