These two files shouldn't be byte-compiled. Until now it was expected
that you'd include a no-byte-compile: t header in these files. This is
more convenient.
Make autoloads will expand the include paths of Doom autoload cookies.
This fixes an issue where paths were expanded to include a file
extension, bypassing the benefits of byte-compilation.
This convenience macro lets you specify multiple packages with one
block, e.g.
(packages! rtags ivy-rtags glsl-mode)
Each entry can be a full recipe.
(packages! (rtags :disable t) (glsl-mode :recipe (...)))
This allows users to disable one master package, thus disabling all its
children. e.g. Disable irony, then irony-eldoc, flycheck-irony,
company-irony and company-irony-c-headers will be disabled too.
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).
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.
+ 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.
Autoload paths used to be relative to arbitrary roots (usually
doom-modules-dir). This commit changes doom//reload-autoloads to iterate
over autoloads in doom-autoloads-file and replace their file paths with
an absolute one.
Theoretically this should make Emacs feel marginally faster, but we
*probably* get more of a benefit from a shorter load-path (because we no
longer need doom-modules-dirs, doom-core-dir or doom-psuedo-module-paths
in the load-path).
This is highly experimental however!
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.
Originally, I built the load-path with site-lisp paths first, then
packages. There was a modest ~10% startup boost doing this, because
there were considerably more site packages loaded at startup than
plugins.
However, this meant built-in packages would get precedence over plugins,
which is undesirable. In org's case, I simply modified the load-path
in lang/org/init.el. However, this issue has cropped up again in #340.
Evidently, that 10% boost may not be worth the risk it imposes, so I've
rearranged the load-path with packages first.
+ map-delete is shorter and faster than assq-delete-all
+ map-put is simpler than the delete-then-set workflow
+ map-merge is great for merging default and user settings
`get-file-buffer` returns nil if no buffer for that file already exists.
In an edge case on Windows, `update-file-autoloads` doesn't leave
a hanging buffer, possibly ignoring its SAVE-AFTER argument. Using
`find-file-noselect` fixes this, which will open a buffer if one doesn't
already exist.
Now that the org ELPA archive has https support, we can add it to
package-archives. This fixes some 'org is unavailable' errors when
installing org packages that have declared earlier versions of org as
a dependency.
This also makes installing a newer version of org-mode much simpler.
Woo!
This causes errors because of arbitrary module load order. This happens
in Emacs 25.x, because hash-table-keys there uses maphash, while in
Emacs 26+ it uses cl-loop.
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.
User module (named after user-login-name) is no longer automatically
loaded or detected, and must be explicitly mentioned in the doom! macro
of your emacs init.el file.
Also, any module can now have an init.el file, which will be run before
any modules are loaded.
Use-package broke in a recent update, as with Doom, since it relies so
heavily on it. To combat this issue arising again, use-package will be
installed from melpa-stable from now on.
Addresses #283
