If doom-emacs-dir contains a "~", attempting to call `git -C` will fail
with an error like:
fatal: cannot change to '~/.config/emacs/': No such file or directory
Fix this by canonicalizing the filename.
I prefer to be more explicit about these variables' defaults, then to
rely on proper load order and unverified global state to ensure they're
properly set.
BREAKING CHANGE: This finally removes 'doom refresh'. It was first
deprecated in 8a77633 and disabled in 8c37928, and has long since been
replaced with 'doom sync'.
Ref: 8c37928de2
Ref: 8a7763337d
And emit more informative errors if they fail.
This eval-when-compile approach is used in preparation for v3, where
Doom's core libraries will be byte-compiled.
This was done to purge superfluous files from Doom's project structure
and simplify its entry points. And with early-init.el now acting as
Doom's universal bootstrapper (see c05e615), we don't have enough
bootstrap logic to warrant being its own file.
Also removes the redundant version check, given doom.el is assured to be
loaded before doom-cli, and performs its own check.
Ref: c05e61536e
A concise alternative to the file IO elisp idioms we're used to,
involving some combination of with-temp-file, with-temp-buffer,
insert-file-contents, coding-system-for-{read,write}, write-region, read
loops, print-to-current-buffer loops, etc.
These were engineered to make reading/writing text and lisp data from/to
files simpler, and will be used extensively in the v3 CLI.
Consecutive expand-file-name and recursive apply's can be expensive, so
the function has been simplified to rely more on file-name-concat. This
does change one trait about it, however: absolute paths in SEGMENTS no
long reroot the whole path, and are concatenated as ordinary file
segments.
The performance benefit is more pronounced on Emacs 28+, and will be
even more so when Doom later starts byte-compiling its libraries.
There are two issues here.
1. Projectile uses file-remote-p to check for remote (tramp) paths in
its known project list, when it automatically cleans it up on
projectile-mode's activation. This causes tramp.el to be loaded,
which is expensive.
2. file-remote-p relies on an entry in file-name-handler-alist
(autoloaded by tramp.el) to detect remote paths, which causes tramp
to be loaded. However, Doom sets file-name-handler-alist to nil at
startup for a noteable boost in startup performance.
Normally, this is not an issue, as I defer projectile-mode until well
after file-name-handler-alist is restored, but it is trivial for a
user to inadvertantly load it too early (often as part of another
package that depends on it, or by blindly following projectile's
install instructions and calling projectile-mode themselves).
In order to address both of these, I defer projectile's cleanup process
altogether. Another approach I considered was to ensure projectile-mode
wasn't activated until the right time, regardless of when projectile is
loaded, but this may trouble savvier Emacs users who need projectile's
API early during startup, so it needs more consideration.
Fix: #6552
Ref: bbatsov/projectile#1649
Rather than impose a 10-45min compilation step on users, I've disabled
ahead-of-time compilation for deferred compilation. In exchange, it will
eat up some CPU time the first time each uncompiled package is loaded,
but as this happens asynchronously (and are then quietly loaded in the
background), I think this is acceptable.
An --aot switch (or similar) will be added to `doom sync` and `doom
build` in the future, in case folks prefer the old behavior.
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.
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
This was brought over from `doom-info` in f33d8e7, but one of the
lexical function calls wasn't refactored out.
Ref: a5c80fcb4b/lisp/lib/debug.el (L216-L219)Fix: #6698
Amend: c5e3f4d632
Co-authored-by: ivanbrennan <ivanbrennan@users.noreply.github.com>
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.
