Refactor after! macro
Refactor after! macro

The trouble with with-eval-after-load is it arranges for the body to be
byte-compiled, whereas eval-after-load does not. I won't go into how
they do that here, but it causes us some trouble:

Macro calls in with-eval-after-load are eagerly (immediately) expanded
at startup, whether or not the package or macro is available and
regardless of its execution path.

This sucks for Doom because, when expanded, autoloaded macros will be
loaded, along with whatever baggage they've got with them, and this
happens long before they're actually used. We also can't guarantee those
macros are available at startup, which will cause void-function errors
when the interpreter later treats them like an ordinary function call.

So, the simple fix is to pass a quoted body form to eval-after-load
instead of the closure that with-eval-after-load will wrap it in. This
means the body won't get byte-compiled if we compile our config, but in
exchange, macros stay lazy-loaded until they're finally needed!
Wonderful.

hlissner/.emacs.d,hlissner/.emacs.d,UndeadKernel/emacs_doom,UndeadKernel/emacs_doom,UndeadKernel/emacs_doom,UndeadKernel/emacs_doom,hlissner/.emacs.d,UndeadKernel/emacs_doom,hlissner/doom-emacs,hlissner/doom-emacs,UndeadKernel/emacs_doom,UndeadKernel/emacs_doom,hlissner/doom-emacs,hlissner/.emacs.d,hlissner/doom-emacs,hlissner/doom-emacs,hlissner/.emacs.d,hlissner/.emacs.d,hlissner/.emacs.d,hlissner/.emacs.d,hlissner/doom-emacs,hlissner/doom-emacs