BREAKING CHANGE: This backports some architectural choices from v3.0.
This changes Doom's module API, renaming some functions and removing
others, in order to facilitate some new features, prepare to move Doom's
modules into separate repos, and make way for two, much larger breaking
commits coming in the next few days.
This commit won't break anything for users unless they're tinkering with
Doom's internals/using its `doom-module-*` API directly. I am avoiding
broader backwards incompatibilities until the 3.0 release.
What's new:
- Negated flags. (modulep! :editor evil -everywhere) will return non-nil
if :editor evil is active without its +everywhere flag.
- `modulep!` now takes multiple flags to simplify AND checks. E.g.
(and (modulep! +foo)
(modulep! +bar)
(not (modulep! +baz)))
Can now be expressed with:
(modulep! +foo +bar -baz)
- Adds pcase matchers for `doom-module-context` and `doom-module`
structs, making the following destructuring binds possible:
(pcase-dolist ((doom-module group name flags features)
(hash-table-values doom-modules))
...)
This will be used more in v3.0.
- Adds file cookie support to module init.el and config.el files.
Here's a summary of breaking changes made in this commit:
- `doom-module-context` was changed from a vector to a struct (record).
- `doom-modules` is now a table of `doom-module` structs, rather than
free-form plists.
- The following macros have been renamed:
- `doom-context-with` -> `with-doom-context`
- `doom-module-context-with` -> `with-doom-module`
- The followings functions have been replaced/removed:
- `doom-module-context`+`doom-module-context-get` -> `doom-module`
- `doom-module-set` -> `doom-module--put`
- `doom-module-p` -> `doom-module-active-p`
- `doom-module-context-key` (is now a getter with the same name)
- `doom-module-put` (removed)
- `doom-module--context-field` (removed)
- The signatures for these functions have changed:
- `doom-module-get CATEGORY &optional MODULE PROP` ->
`doom-module-get (GROUP . MODULE) &optional PROP`
- `doom-module-locate-path CATEGORY &optional MODULE FILE` ->
`doom-module-locate-path (GROUP . MODULE) &optional FILE`
- `doom-module-expand-path CATEGORY MODULE &optional FILE` ->
`doom-module-expand-path (GROUP . MODULE) &optional FILE`
- Adds the following functions
- `doom-module-exists-p`
- `doom-module-key`
- `doom-module->context`
- `doom-module<-context`
- Removes the following variables
- `doom-module--empty-context`
This commit results in a little redundancy, which I will address in
parts 2/3 and/or v3.0.
Eventually, I want to autoload some of this stuff, so that users in
interactive sessions can safely load it without side effects (useful
when writing their own CLIs or editing Doom's source).
sxhash doesn't guarantee hashes are consistent across Emacs sessions, so
use md5 instead. Also simplifies what's getting hashed;
`system-configuration` is a sufficient substitute for both `system-type`
and what I wanted to glean from changes in
`system-configuration-features`.
Amend: 80e9263b85Close: #8030
Ref: #8024
Co-authored-by: yaaama <yaaama@users.noreply.github.com>
Turns out native-comp doesn't respect
`native-comp-jit-compilation-deny-list` if called explicitly (instead of
from deferred compilation).
Fix: #5592Fix: #6283Fix: #3655
I intend to eventually replace projectile with project.el, so these
doom-projectile-* variables need to be generalized, starting with the
fd/ripgrep executable paths.
ALong with that, this refactors Doom's projectile-generic-command to
lean more on built-in fd support in projectile, where possible (fewer
wheels reinvented).
Ref: doomemacs/core#1
Allow ahead-of-time native-compilation during CLI operations that
install or update packages. This will not retroactively native-compile
already-installed packages, you'll need to use --rebuild to do so.
(This is a stop-gap solution until the v3.0 release)
Fix: #6811
When running `doom sync --rebuild` after emacs upgrade the user is
prompted with "Installed packages must be rebuilt. Do so now?", even
though doom was explicitly instructed to rebuild. This PR removes this
prompt when the `--rebuild` option is provided
Before this, text that extended past the new line's length would
persist, causing garbled output like this:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Cloning org-appear...r emacsmirror-mirror...
- No packages need attention
Which might lead you to believe org-appear is being cloned from
emacsmirror-mirror, but the full output is actually:
> Ensuring packages are installed and built...
> Updating recipe repos...
> Updating recipes for melpa...
> Updating recipes for nongnu-elpa...
> Updating recipes for gnu-elpa-mirror...
> Updating recipes for el-get...
> Updating recipes for emacsmirror-mirror...
> Cloning org-appear...
- No packages need attention
The -!/--force flags suppress straight's 'how to proceed' prompts, but
not the secondary ones like 'Really delete remote "origin"?'. This fixes
that.
Fix: #7906
If the package is local, the local-repo has absolute local file path,
and straight-modified-dir will return as it is, which always exists.
Fix it by passing package only to straight-modified-dir.
Doom makes multiple attempts to re-clone repos if they failed the first
time, however, if a user provides a :local-repo and that location isn't
a git repo, Doom assumes this it is the result of a failed clone, and so
deletes it to "try" again (which will fail). This can result in lost
work.
This prevents this from happening to packages/repos outside of
$DOOMLOCALDIR (all packages under $DOOMLOCALDIR must be git repos).
Fix: #7785
Amend: 3643c4dadd
Amend: 1fa8d3a4b9
directory-empty-p was introduced in 28.1, but Doom still supports 27.1,
so 27.x users would see this error when running any bin/doom command
that clones packages.
Fix: #7779
Amend: 1fa8d3a4b9
It seems the temporary branch that 'doom upgrade' creates is sometimes
left over after a 'doom upgrade', preventing the next 'git fetch' from
completing.
Ref: #7771
Caused by a regression originally introduced in b6b755d, but incorrectly
fixed in 89c56a3. Don't code while sleep deprived, kids.
Amend: 89c56a3393
Amend: b6b755dea4
12a765c introduced suppression of package-rebuilding prompts on 'doom
upgrade', but inadvertently reversed the check. This fixes that (and
refactors the if/or tree into a `cond`).
Amend: 12a765c509
Prior to this, -B would suppress the prompt for package rebuilding if
your Emacs version or hostname changed. Now, it fully inhibits
rebuilding in either case.
Fix: #7760
Ref: cff091982e
