- 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.
Init extra fonts within doom-init-fonts-h. This was moved because I used
to believe that set-fontset-font (according to its documentation) could
only change the frame-local fontset. It turns out that the exception
when you pass t for its first argument, which targets the default (i.e.
global) fontset.
There are a few kinks to iron out, but for the most part it's done. Doom
Emacs, powered by straight. Goodbye gnutls and elpa/quelpa issues.
This update doesn't come with rollback or lockfile support yet, but I
will eventually include one with Doom, and packages will be (by default,
anyway) updated in sync with Doom.
Relevant threads: #1577#1566#1473
- Adds the auto-minor-mode package to replace our in-house
implementation.
- Merges associate! into the def-project-mode! macro because associate!
on its own is less useful than auto-minor-mode-alist,
auto-minor-mode-magic-alist or hooks.
- Changes the semantics of :modes and :add-hooks properties of
def-project-mode!. Its arguments are evaluated as is; lists will need
to be quoted.
squash! core-lib: remove associate! macro
- file! replaces FILE!
- dir! replaces DIR!
- doom-{glob,path,dir} have the power to construct paths out of the
segment pieces provided to it.
- Move doom-files-in to core-lib and refactor to use the above.
Now uses an interned hook name (that could be removed, unlike the
uninterned symbol make-symbol creates).
Also, for consistency: fun -> fn
No fun allowed!
