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.
Any module can now use a doom! call to declare a module tree root.
This means that if you have a doom! block in
~/.emacs.d/modules/lang/org/init.el, then you can have submodules in
~/.emacs.d/modules/lang/org/modules/MODULE/SUBMODULE if you wanted to
for some reason.
This is only really truly useful for private modules. A doom! block in
~/.doom.d/init.el will recognize and enable modules in
~/.doom.d/modules/.
~/.doom.d/modules is now a full module tree, like ~/.emacs.d/modules.
Symlinks are no longer involved.
Private modules can now shadow Doom modules. e.g.
~/.doom.d/modules/lang/org will take precendence over
~/.emacs.d/modules/lang/org.
Also, made doom--*-load-path variables public (e.g. doom--site-load-path
=> doom-site-load-path), and rearranged the load-path for a 10-15%
startup boost.
This is a breaking change! Update your :popup settings. Old ones will
throw errors!
Doom's new popup management system casts off its shackles (hur hur) and
replaces them with the monster that is `display-buffer-alist`, and
window parameters.
However, this is highly experimental! Expect edge cases. Particularly
with org-mode and magit (or anything that does its own window
management).
Relevant to #261, #263, #325
Local cache and data files were stored in a parent folder named after
your host, because I'd symlink the same config across computers via
dropbox. This would cause byte-compile issues in packages, so I stopped
doing this.
Now that each computer gets its own clone, host-namespaced local
directories are unnecessary. There's no other benefit to having them.
