It seems either Emacs' warning library and/or debugger relies on
custom.el functionality at load time to properly function. If
`custom-dont-initialize` is non-nil when a warning or error occurs,
Emacs fails to fully load the `warning` or `backtrace` libraries,
causing this error to obscure the true warning/error with:
Error in delayed-warnings-hook (display-delayed-warnings): (void-variable
warning-minimum-log-level)
`doom-module-load-path` will be removed in the next big refactor commit,
so as a stop gap, I simply move it to doom.el to resolve the reference
error.
This also removes the obsolete alias `doom-modules-dirs`, since it's
been deprecated long enough (and `doom-module-load-path` itself won't be
around much longer anyway).
Ref: #8147
Amend: 8cafbe4408
The issue required a more systemic fix, because the former (before
9e6c46a even) only recorded `Info-directory-list` for the packages that
were installed/updated in that `doom sync` session, forgetting all
packages installed in the past.
Fix: #8143
Amend: 9e6c46a332
Autoloads were accidentally reversed in 114f996. For some packages,
autoload order is signifcant (such as json-mode, which autoloads
json-mode-auto-mode-list first, then modifies it in a later autoload).
Fix: #8143
Amend: 114f99688c
Some packages do funky things in their autoloads, so care is needed to
closely emulate an autoloading environment when loading them, however,
in 8cafbe4, Doom wraps these autoloads in a function, thus ensuring
they're executed without `load-file-name` or `load-in-progress` set,
which some packages will expect these in their autoloads.
This fixes the (wrong-type-argument stringp nil) error some folks see
with certain packages doing said funky things in their autoloads (like
realgun in the :tools debugger module).
Fix: #8143
Amend: 8cafbe4408
'doom upgrade' naively evaluates straight's recipe so it can delete
it (so 'doom sync' will upgrade it), but the
`straight-repository-branch` reference will error out for users updating
Doom from before 8cafbe4 to a commit after it, since its value now lives
in `doom-straight`, which may not be loaded yet.
Rather than further embed this hack (and because I don't want to spend
more time on straight.el accommodations than I have to, since it'll be
replaced with Elpaca soon), I simply replace the reference with its
value.
Fix: #8140
Amend: 8cafbe4408
Seems these two macros were marked obsolete very recently on Emacs 31.1
in favor of (if|when)-let*. Since the change seems premature (judging
from the mailing list discussion), and because I disagree with the
change (and will redefine (if|when)-let if they actually go through with
removing them), I simply silence the warnings altogether. They're not
helpful for the end user and end up only spamming them with unactionable
warnings.
I'll wait until upstream figures it out before I make any decisions.
Ref: https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00637.html
BREAKING CHANGE: This restructures Doom's core in an effort to slim it
down and partially mirror architectural changes coming in v3. This is
part 2 of 3 commits (part 1 being 1590434), done to facilitate a change
in part 3 that will introduce a new `doom!` syntax for pulling
third-party module libraries from remote sources (similar to `package!`
statements). I am backporting this from V3 so I can move our modules out
into separate repos sooner than later, so development on modules can
continue separately without interfering with v3's roll out.
Though this is labeled a breaking change, it shouldn't affect most users
except those few tinkering directly with Doom's internals.
Ref: 15904349cf
Recent changes to early-init.el accidentally moved some arguments
intended for `load` to an inner `let`, which means only the last
argument gets passed to `load`. This results in
```
> Debugger entered--Lisp error: (wrong-type-argument stringp nosuffix)
> load(nosuffix)
> (or (load (let ((windows? (memq system-type '(ms-dos windows-nt cygwin)))) (expand-file-name...
```
when starting Doom (or running a doomscript) with DOOMPROFILE set.
Move these arguments back out of the `let`.
Amend: 9ae7aa1122
This prevents edge cases where these directories are created with
permissions that prevent Emacs from writing to them. This can happy
either due to an overly-restrictive default umask,
`set-default-file-modes` call, or if `doom-profiles-save` is instructed
to write a file whose parent doesn't exist yet.
Fix: #8134
Because this file serves as a global manifest for Doom's profiles, it
should be kept in a central location for any Doom instance to consult,
rather than per-instance. Plus, post-v3 Doom will only write files to
$XDG_*_HOME and $TMPDIR, therefore I'd like to avoid writing to
$EMACSDIR.
This change shouldn't affect end-users, in any case. Run 'doom sync' to
regenerate the file, which should happen when you run 'doom upgrade'
anyway.
Fixes the broken Agda auto mode in Doom Emacs caused by the
introduction of mimer in Agda 2.7.0.
* modules/lang/agda/config.el (agda-auto-mode):
replaced agsy with mimer for auto mode call.
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.
factor/fuel@31dc1a386b -> factor/fuel@6d0e98494f
Melpa's upstream and recipe for `fuel` changed (see
4a3d7cdefa):
previously it was pulled from a subdirectory of the main `factor`
repository, it now has its own repository. Applying Doom's previous pin
to the new recipe does not seem to work correctly, so update.
Toggle behavior:
The `(integerp current-prefix-arg)` check didn't appropriately catch
`C-u`/`SPC u` prefixes. This attempts to use `(prefix-numeric-value
current-prefix-arg)` instead to normalize these cases.
Variable naming:
I'm not sure if this was supposed to continue to be called
`+mu4e-compose-org-msg-toggle-next` or if the rename to private
`+mu4e--compose-org-msg-toggle-next` was intentional and the usage
wasn't updated accordingly. I see the `mu4e` README still mentions it,
so I would guess the former and this was a typo.
Ref: #8073
Amend: a78237cc01
These two commands were renamed upstream and pulled in in 1fa1eba:
- python-pytest-function-dwim -> python-pytest-run-def-or-class-at-point
- python-pytest-function-dwim -> python-pytest-run-def-or-class-at-point-dwim
Amend: 1fa1eba5ac
Ref: wbolster/emacs-python-pytest#75
