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.
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.
