:defer now supports a hook, a cons cell with (SYMBOL . INTEGER) where
SYMBOL is a hook and INTEGER is a number of idle seconds before the
package is autoloaded, or just the integer (as per the default behavior
of :defer).
Also fixes an issue where switch-buffer-deffered packages (like
smartparens) wouldn't load.
+ New `input` and `buffer` support for :defer in def-package! can now
defer packages until the first command invoked after startup or first
interactive buffer switch, respectively
+ Exploit these new :defer techniques to lazy-load many core packages,
netting Doom a 20-30% decrease in startup time
+ Various userland macros (like package!, def-package-hook!, packages!,
and disable-packages!) will now throw an error if used incorrectly
(i.e. outside of their intended files; e.g. package! should be used in
packages.el files)
+ Removed support for multiple/nested doom! calls. There should only be
THE ONE in ~/.doom.d/init.el (or ~/.config/doom/init.el)
+ Fix an issue where load-path and auto-mode-list modifications would
not persist because doom-packages-file was cached too late.
+ Added package-activated-list to cached variables in
doom-packages-file, thus we no longer need custom-file.
+ Load Doom core files from doom-initialize. Now doom-initialize can be
called from state-dependent non-interactive functions, instead of
reloading core/core.el, which was clumsy
+ Removed the doom-post-init-hook hook. There was no reason for it to
exist when doom-init-hook can simply be appended to
The config/private module has been removed. ~/.doom.d (or
~/.config/doom; whichever is detected first) is now a first class
citizen of Doom and should just work(tm).
Your init.el only needs to contain:
(require 'core (concat user-emacs-directory "core/core"))
And you may place your doom! block in ~/.doom.d/init.el (or
~/.config/doom/init.el).
This makes package.el commands safe to use in Doom, and prevents errors
caused by unitialized state, by running package-initialize before
you use a package.el command.
Formerly, you were required to have a doom! call (even a blank one) in
~/.doom.d/init.el if you wanted to have private sub-modules in
~/.doom.d/modules/.
No more. It is no longer doom!'s responsibility to affect
`doom-modules-dirs`. This is now done by :config private, while the
Doom modules directory is now the initial entry in doom-modules-dirs.
