+ Move doom-initialize et co into core.el
+ Lazy load core-packages
+ load! has been moved into core-lib
+ Added FILE! and DIR! macros
+ Fix package! not returning correct value when package is disabled
+ Remove :disabled support for def-package-hook! officially
Removes doom-module-table; which was inflexible (though more stable). It
prevented you from putting your doom! block in anywhere but
~/.doom.d/init.el.
It is replaced (somewhat) by (doom-modules).
The autoloads file has been split into doom-autoload-file and
doom-package-autoload-file. The former is for Doom's modules and
standard library; the latter is for compiling all package autoloads like
load-path and auto-mode-alist (among other things).
This reduced my startup speed from ~1s to ~0.5s
This offloads some of the work Doom has to do creating
`doom-packages-file` onto `make autoloads`. This closely mimics the
package-quickstart-refresh functionality in Emacs 27+, but is more
specialized.
This means package autoloads are now loaded on every startup.
Many :mode, :interpreter, and :commands declarations in def-package!
blocks are made redundant by this and will be cleaned up soon.
: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).
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.
+ Fix#446, where the .local/packages.el cache was generated with
a faulty load-path.
+ Entries in the doom-modules hash table are now plists, containing
:flags and :path, at least.
+ Add doom-initialize-modules for loading module config.el files.
+ Add doom-module-get for accessing this plist, e.g.
(doom-module-get :some module) ; returns plist
(doom-module-get :some module :flags) ; return specific property
+ Replace doom-module-enable with doom-module-set, e.g.
(doom-module-set :some module :flags '(+a +b +c))
+ Remove doom-module-flags (use doom-module-get instead)
+ Rename doom-module-enabled-p with doom-module-p
+ Replace doom-module-path with doom-module-find-path and
doom-module-expand-file. The former will search for an existing module
or file in doom-modules-dirs. The latter will expand the path from
whatever path is stored in doom-modules.
+ Replace doom-module-paths with doom-module-load-path
+ Changed doom! to allow for nested doom! calls by delaying the loading
of module config.el files until as late as possible.
+ Refactor doom-initialize-packages to only ihitialize package state
(i.e. doom-packages, package-alist, and quelpa-cache), rather than its
previous behavior of loading all Doom files (and sometimes all module
files). This is faster and more predictable.
Doom saves a lot of startup time by avoiding package-initialize, because
it loads every packages' autoloads file, which is expensive.
Unfortunately, these autoloads files are necessary for some plugins with
abnormal file structures (such as ESS). Previously, I was content with
loading them myself, but these occurrences have become more frequent, so
it would be safest if I relied on package-initialize more.
So doom-initialize will now do so. However, it will cache the load-path
(and Info-directory-list, fixing the lost info buffers) on first run.
This makes byte-compiling Doom almost useless, but it makes startup just
as fast as Doom would be if you had.
This needs more testing.
