+magit-display-buffer-fullscreen is a more sophisticated (albeit
experimental) replacement for magit-display-buffer-fullframe-status-v1,
which fullscreens magit, but will also:
a) Keep the status window visible
b) Treat magit buffers not opened from magit-status as popups
This really seems like it should be a default, it's so handy to get
better diffs, sort of like how github does it. if set to 'all then it'll
show on all of them, but I think t is good enough.
It will tangle and byte-compile a config.org in your private config.
Doom will then load the resulting config.elc later.
Org is only loaded when updating this file.
Some packages (like evil-collection and dumb-jump) use helm macros, but
Doom cannot ensure helm will be installed by the time these packages are
byte-compiled during installation. In fact, the default load order
prevents this.
Rather than imposing hard load order requirements, we just make sure
helm is higher on the packages list, so it gets installed sooner.
evil-org-set-key-theme blanks out evil-org-mode-map, undoing all our
custom keybinds. Using it isn't the correct way to customize evil-org,
but it is understandable people would use it expecting it to be, so
`+org|setup-evil` will now run after it is called.
The "Doom" way to customize evil-org would be to modify the
`evil-org-key-theme` variable, but with this change, either will work.
+ Group hooks with add-hook!
+ Sharpquote elfeed call
+ Extract elfeed buffer detector into function and ensure idempotency of
doom-real-buffer-functions
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.
