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.
These two files were removed in ccb5fde9bcc on the rewrite-docs branch,
which was merged in 1f8bf7accb. I planned to add their rewritten
versions soon after, but life and distractions got in the way, so I'm
restoring the old ones until I finish the new ones.
Fix: #6748Fix: #6723Fix: #6671Fix: #6631Close: #6726
Revert: ccb5fde99b
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
This centralizes Doom's core startup optimizations and, as a
side-effect, reduces the runtime of bin/doom commands substantially.
This also simplifies the user story for loading Doom remotely (for batch
sessions or doomscripts).
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.
If an error occurs before this is restored, this can leave Emacs in a
state where it appears frozen and won't redraw. This can be overcome by
hooking into the debugger, but I'll try that another day.
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
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.
There are some conventional files strongly associated with a non-bash
shell which do not use an explicit `.zsh` file extension (e.g.
`.zprofile`); the old logic would always use the `#!/usr/bin/env bash`
shebang in these cases, which is a tiny little bummer.
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.
