Emacs 27.x does not collapse consecutive slashes in a file path when
trying to load them, and instead discards everything before it and
treats the rest as an absolute path, e.g. "~/some//path/foo/" ->
"/path/foo". This is not the case in 28.1, but Doom's backport of
file-name-concat did not take this into account, so it's been modified
to trim trailing slashes.
Fix: #6766
Amend: 433c9e344d
Relying on eval-after-load's compiler-macro magic (after 8b4f722) can
cause scope issues with nested macros (like file! and dir! running in
the context of a temp buffer), so best we use with-eval-after-load
directly.
Ref: 8b4f722fa3
To ensure that they're expanded at a file's top-level, while expanded,
where they're used. It also fixes a few inlined uses of the file!
macro (e.g. in `load!`, as reported in #6764), which was prematurely
committed ahead of this change.
Close: #6764
Amend: a179b8d262
These functions are light wrappers around require and load, such that
Doom will catch (and decorate) any errors from the target file, and is
also capable of loading Doom's subfeatures.
In the future, doom-lib (among other things) will be byte-compiled as
part of 'doom sync'. To spare runtime the overhead of checking for these
functions, I've wrapped these in a macro. It also makes their
definitions a tad simpler.
If defer-feature! was called with one argument (as is the case in the
:lang common-lisp module), FNS defaulted to an empty list. As a result,
FEATURE was deferred but never re-added to the features list, and after!
blocks were never triggered.
Instead of defaulting to an empty list, fallback to a singleton list
containing just (FEATURE). This aligns with the behavior this macro had
prior to 5b8b04f0c8, which generalized FNS
to support a list of functions rather than just one.
It used to be that after! suppressed macro expansion, but at some point
around 28.1, the elisp interpreter started recognizing the
compiler-macro hint in eval-after-load's definition; implicitly wrapping
quoted forms in a function. Therefore, we can no longer rely on
eval-after-load to hide macros from the byte-compiler. Instead, modules
will need to take care to wrap macro calls in `eval` or similar, on a
case-by-case basis.
This fixes a couple bugs with this macro:
- Nested %-refs (in nested fn!'s) were interpolated as arguments of the
outer-most fn!. E.g. (fn! (fn! %2)) would expand to:
Before this fix:
(lambda (_%1 %2)
(lambda (_%1 %2)
%2))
After this fix:
(lambda ()
(lambda (_%1 %2)
%2))
- Unused arguments were not only listed in the wrong order, they were
off-by-one. E.g.
(fn! %3 %5) expands to (lambda (_%4 _%3 %3 _%1 %5) %3 %5)
This never caused any actual issues, but it was unexpected.
I've also moved the lookup table to `fn!`, and removed unnecessary
entries from it.
- 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'.
Unsetting file-name-handler-alist around a `load` call prevents any
change to this variable from surviving that file's evaluation (e.g. by
packages loaded therein). Since the user's config files are loaded with
this macro, this affects users' configs, which is unacceptable.
Since this optimization is already done in early-init.el, we can get
away with being more selective here.
doom-enlist is now a deprecated alias for ensure-list, which is built
into Emacs 28.1+ and is its drop-in replacement. We've already
backported it for 27.x users in doom-lib (in 4bf4978).
Ref: 4bf49785fd
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
