Making the compile check happen earlier fixes an edge case where the
resulting files from a literate config being tangled into multiple files
aren't recognized by Doom's package management or autoload generation
systems.
Disabling byte-compiling fixes an all too common issue where packages
and macros are undefined at compile time, causing a plethora of invalid
function errors.
Leave byte-compilation to `bin/doom compile`!
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.
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.
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
load!'s first argument is no longer a symbol (that will cause
void-variable errors now) to save on unnecessary interning and simplify
compile-time logic. It accepts any valid form that evaluates to a string
now.
If you use load!, you need to change its argument to a string!
e.g. (load! +my-module) => (load! "+my-module")
Now that we are loading package autoloads files (as part of the
generated doom-package-autoload-file when running make autoloads), many
:commands properties are redundant. In fact, many def-package! blocks
are redundant.
In some cases, we can do without a config.el file entirely, and can move
into the autoloads file or rely entirely on package autoloads.
Also, many settings have been moved in their module's autoloads files,
which makes them available ASAP; their use no longer depends on module
load order.
This gained me a modest ~10% boost in startup speed.
