They are now included in doom-packages, but with :private t or :disabled
t properties. This allows us to search for them if we wish (e.g. for
doom info).
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).
Normally doom|show-whitespace-maybe turns on whitespace-mode with a
subset of its features when indent-tabs-mode was different in that
buffer versus it's global default. e.g. If your default was spaces and
you opened a file with tabs.
This is to make it easier to notice whitespace style discrepancies.
However, it have side effects if whitespace-mode/global-whitespace-mode
was already on.
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.
