The fix is quite simple once I grokked some basics of how package.el works.
First, evil-mode is an "autoloaded" minor mode, which means that
(despite an M-x command being available) the evil namespace/module isn't
loaded at startup. This explains why `eval-after-load` wasn't working.
(Although, M-x evil-mode does cause the evil ns to be loaded, which then
triggers the evaluation of any expression(s) provided to
`eval-after-load`, which explains some bizarre error messages I
occasionally got when figuring this all out.)
Second, "packages are initialized AFTER the init.el is loaded"[1] (it
helps to read docs, eh? :-P) A couple of ways to get around this include
using 'after-init-hook (which looks more promising in general), and the
brute-force method of simply initializing packages when you need them,
as I'm doing for now:
(package-initialize)
(live-load-config-file "evil.el")
The right way to do things is probably something like:
(add-hook 'after-init-hook (lambda () (live-load-config-file "evil.el")))
…but, it appears that `live-load-config-file` is doing little more than
(load (str "./config/" short-filename-here)), which won't work in a
hooked context, so I'd need to hardcode absolute path loads into my
local pack anyway. Not so great.
Perhaps the most ideal thing would be if emacs-live ran its entire
pack-initialization process via an 'after-init-hook lambda. I tried this
in ~/.emacs.d/init.el:
(add-hook 'after-init-hook (lambda () (mapcar (lambda (pack-dir)
(live-load-pack pack-dir))
(live-pack-dirs))))
…and my init.el worked without a problem, _sans_ the perhaps-hacky
`(package-initialize)` call. Maybe this is a reasonable change to bring
the emacs-live and package.el worlds a bit closer together? At least,
AFAICT, it makes it so that I can write my local pack(s) to use ELPA
packages and/or submodules interchangeably.
Cheers,
- Chas
[1]
http://www.emacswiki.org/emacs/ELPA