+ 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.
evil keeps track of auxiliary keymaps. This list is updated when you
switch states, but it _really_ needs to be updated when minor
modes (with keymaps) are toggled. When this isn't done, their keymaps
aren't recognized and their keys will be unavailable at first.
Since there is no global hook for enabling minor modes, we have to
manually add evil-normalize-keymaps to minor mode hooks.
This commit, specifically, fixes evil-org-mode-map. This also indirectly
fixes folding src blocks for evil users (on the first org buffer).
Adds +helm/project-search, as well as +helm/ag and +helm/ag-from-cwd,
and variants for rg, pt and grep/git-grep, to mirror the functionality
available to :completion ivy.
Also updates the evil ex commands and keybinds
This new default was chosen to keep magit consistent with fullscreen
:app workflows (which work very similarly). It is also more predictable
than the default method.
Not a common necessity when writing markdown, and slows down modes with
markdown submode regions (like magithub, when initializing issue/PR
bodies).
This is easily toggled with markdown-toggle-math anyway.
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.
