Possibly fixes recursive load errors, to do with
kill-buffer-query-functions and buffer-predicate autoloads loading in a
weird way on Emacs 25 (and especially on MacOS, for some reason).
doom! no longer loads modules, it only sets
doom-modules (incrementally).
Instead, modules are loaded by doom-initialize-modules (which makes more
sense).
Now (featurep! :category module +flag) will work properly check for
+flag rather than just returning t if :category module were enabled.
Also update variables to match category-module nomenclature.
Defer its compile-time segments to run-time, which would cause many
issues in conditions wrapped around it.
In any case, avoid using require!, it was a poor choice to implement it
and should only be used for unit tests.
After some profiling, it turns out map-put and map-delete are 5-7x
slower (more on Emacs 25) than delq, setf/alist-get and add-to-list for
small lists (under 250 items), which is exactly how I've been using
them.
The only caveat is alist-get's signature is different on Emacs 25, thus
a polyfill is necessary in core-lib.
Another refactor, again to improve the locality of doom errors and make
the data that accompanies them more useful in determining the origin and
source of issues. Also, bin/doom is now a little more informative about
how to debug errors.
The error handlers were a little too effective. They obscured a large
chunk of the stacktrace after errors, even in debug mode. This fixes
that and ensures backtraces in debug mode are more helpful.
This fix prevented the byte-compiler from trying to load packages that
were disabled or failed their :when/:unless/:if predicates. This commit
moves it into doom-byte-compile, so the :no-require predicate doesn't
have to run on every package in an interactive session, eating MY
PRECIOUS cpu cycles.
I do love my cpu cycles, yessiree.
This will hopefully reveal more information as to the cause and origin
of errors at startup. It should also make doom-debug-mode more likely to
produce a backtrace in non-interactive sessions.
Rely on use-package mechanisms. def-package! should be as thin a wrapper
as possible. Ideally, we should simply be an alias, but there is no way
to inject :disabled into a use-package declaration, because it is
treated especially.
+ :popup -> set-popup-rule!
+ :popups -> set-popup-rules!
+ :company-backend -> set-company-backend!
+ :evil-state -> set-evil-initial-state!
I am slowly phasing out the setting system (def-setting! and set!),
starting with these.
What are autodefs? These are functions that are always defined, whether
or not their respective modules are enabled. However, when their modules
are disabled, they are replaced with macros that no-op and don't
waste time evaluating their arguments.
The old set! function will still work, for a while.
use-package-handler/:after-call was (accidentally) relying on the
dynamic value of `name`, but now that use-package uses lexical binding,
this isn't possible anymore, causes errors.
+ 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
