When appending multiple functions to a hook(s) with add-hook!, insertion
order was not preserved. e.g.
=> (add-hook! :append 'some-mode-hook #'(hook-1 hook-2))
=> some-mode-hook
(hook-2 hook-1)
In certain edge cases, the buffer/window/frame switch would not make the
new buffer/window/frame current, which is what the after switch hooks
should reasonably expect, causing some shenanigans.
For example, persp wouldn't register magit buffers because
`doom-after-switch-buffer-hook` was run in the context of the previous
buffer.
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.
Byte-compiling should be a considered an advanced workflow. Warn users
of the dangers. The prompt can be suppressed with the -y option. e.g.
bin/doom -y compile
You won't get the prompt for byte-compiling :core or :plugins however.
This is in preparation for general.el integration coming in 2.1.1. It is
very likely that map! will change (and even more, be split into several
macros). Not much, but change none-the-less. Specifically, the state
keywords (e.g. :nvi, :n, :i) will be removed in favor of a :state
property that takes a list, e.g. (normal visual insert).
In any case, both map! and general are also relatively expensive
compared to define-key and evil-define-key* (and the new define-key!
macro), so use that when we can.
This also means changes to either API won't affect Doom's modules in the
long term.
The package autoloads generator wouldn't take module packages.el files
into consideration when detecting whether the autoloads file should be
regenerated. Now it does.
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.
Due to changes under the hood, the :files FORM property requires FORM to
either be a nested form of and/or sexps, or a single string. This is
inconsistent with the plurality of ":files", so it has been fixed to
accept a list of strings (with an implicit (and ...)).
