Caused lecause straight is prompting for input in a headless
session *and* from a headless async child instance of Emacs. It waits
forever for input for a question we could never see or respond to.
How sad.
- Let-bind byte-compile-* vars instead of using file-local vars.
- Fix duplicate bullet point in "Copied backup..." message.
- Only display refresh message if cli command was successful.
Straight expects to be used interactively, which don't do (yet). Its
transactional system depends on idle timers, which don't run in a
noninteractive session, so we have to nudge it ourselves.
- Now handles errors from threads gracefully, rather than failing
silently.
- Exploits straights modification system to trigger rebuilds
later (instead of force-rebuilding after each update).
Before this update, the autoloads files were collected in
lexicographical order (by traversing straight's build directory). By
using straight--build-cache's keys (which are entered in the order they
were registered) we avoid issues like
This commit does two things:
- Renames def-advice! to defadvice!, in the spirit of naming convenience
macros after the function/macro they enhance or replace.
- Correct the names of advice functions to indicate visibility and
intent. A public advice function like doom-set-jump-a is meant to be
used elsewhere. A private one like +dired--cleanup-header-line-a
shouldn't -- it likely won't work anywhere but the function(s) it was
made to advise.
Calling this pivotal macro "def-package!" has frequently been a source
of confusion. It is a thin wrapper around use-package, and it should be
obvious that it is so. For this reason, and to match the naming
convention used with other convenience macros/wrappers, it is now
use-package!.
Also changes def-package-hook! -> use-package-hook!
The old macros are now marked obsolete and will be removed when straight
integration is merged.
- Eager-load all core autoloaded libraries if autoloads file isn't
present.
- Renames functions to be more descriptive of their true purpose:
- doom-initialize-autoloads -> doom-load-autoloads-file
- doom-load-env-vars -> doom-load-envvars-file
- Use doom-module-p instead of featurep! for backend use (the latter is
mainly syntax sugar for module use, and evaluates at compile/expansion
time, which may cause hash-table-p errors early in the startup
process).
- Reorder plist library to prevent load order race condition with the
functions using the macros that haven't been defined yet.
It would no-op if you responded "y" to the 'update them?' prompt, and
proceed if you responded "n".
Doom must be in its rebellious phase.
Also relevant: #1585
Now returns (:core) or (:private) for files in doom-core-dir and
doom-private-dir, respectively, and will otherwise return the module for
the current file if called with no arguments.
Also fixes the case where it would disregard arguments and return
whatever the current value of doom--current-module.
The trouble with with-eval-after-load is it arranges for the body to be
byte-compiled, whereas eval-after-load does not. I won't go into how
they do that here, but it causes us some trouble:
Macro calls in with-eval-after-load are eagerly (immediately) expanded
at startup, whether or not the package or macro is available and
regardless of its execution path.
This sucks for Doom because, when expanded, autoloaded macros will be
loaded, along with whatever baggage they've got with them, and this
happens long before they're actually used. We also can't guarantee those
macros are available at startup, which will cause void-function errors
when the interpreter later treats them like an ordinary function call.
So, the simple fix is to pass a quoted body form to eval-after-load
instead of the closure that with-eval-after-load will wrap it in. This
means the body won't get byte-compiled if we compile our config, but in
exchange, macros stay lazy-loaded until they're finally needed!
Wonderful.
