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).
Also fixes void-function errors caused by (now removed)
doom-same-emacs-version-p not being defined in all the contexts it was
needed.
Where it was before was clumsy design.
By loading the private packages.el in two passes. The first time ensures
later modules will know about disabled packages and the second time
ensures overwritten packages are properly overwritten.
Not the most efficient, but efficiency is low priority in noninteractive
sessions (i.e. during package management), the performance loss is
negligible, and packages.el files (should) have no other side effects
anyway.
load!'s first argument is no longer a symbol (that will cause
void-variable errors now) to save on unnecessary interning and simplify
compile-time logic. It accepts any valid form that evaluates to a string
now.
If you use load!, you need to change its argument to a string!
e.g. (load! +my-module) => (load! "+my-module")
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 commit adds bin/doom, which acts as the middle man that make once
was (and will stay for a while, though the documentation will shift away
from using it). It does everything the previous make interface did, but
is faster and more flexible. bin/doom should eventually replace the
makefile.
bin/doom also makes it easier to run Doom outside of ~/.emacs.d and
~/.doom.d with, for example:
bin/doom run -p ~/.other.doom.d/ -e ~/.other.emacs.d
bin/doom.cmd is included for Windows users, but I don't recommend using
it yet. It hasn't been tested nor have I ever written a batch script
before.
Also update init.example.el with new defaults.
The would prioritize load-file-name over byte-compile-current-file
during byte-compiling, which would result featurep! being unable to
resolve the current module and load! from figuring out where "here" was
to build its relative paths from.
+ Consolidate the CATEGORY -> MODULE terminology
+ Rename functions to make their function easier to understand
+ Rename doom-module-expand-file => doom-module-path
+ Rename doom-module-find-path => doom-module-locate-path
