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
Post by Sam AaronHowdy all,
apologies - my brain is currently busy elsewhere at the moment, so I'm
only writing this in a fleeting pass...
Just to summarise, I'm very interested in figuring out ways to get
Emacs Live working well with the Emacs package system, so people can
pull in extra things via packages such as how Chas pulled in Evil.
This really should *just work* so any help in achieving this is
happily received. I personally don't use the package system, but would
like to support people that do.
On the other hand the advantages (to me), of moving Emacs Live to a
complete package oriented system isn't completely clear at this stage.
One of the core engineering goals of Emacs Live is that it's easy for
me to hack on it, pull things in and make releases. If I have to start
managing a number of packs independently and add more stages to
releasing builds, it only serves to add more friction. Currently, I
use git submodules as it gives me extremely fine-level control of the
dependencies. I don't assume that any users use submodules, it's just
for dev use. I have a simple script which copies all dev stuff into a
separate directory for releases which is super simple to work with.
Keeping the maintenance efforts of Emacs Live down is super important
to me.
I should also add that in no way am I closed to any further debate on
these matters. I'm always happy to be convinced otherwise on any
matter :-)
Sam
---
http://sam.aaron.name
Post by Wes MorganPost by Chas EmerickTo clarify, I'd like to consume libraries/packages/etc in whatever
way their maintainers support/expect; so, evil (and many other
libraries) from package.el repositories, and emacs-live from git and
submodules. This really works just fine right now AFAICT, except for
this niggling bit about boot-time load ordering and such (i.e. I'm
happily using emacs live and evil and a variety of other packages,
though I need to enable evil manually at the moment).
Which is exactly what my fork does. The live packs will be listed in
a package.el repo, and if you install them, it will pull in the
upstream package as a dependency, installing it in the usual way. So,
for example, if you installed the evilmode-pack, it would pull in the
evil package from MELPA.
If you then decided you didn't like the evilmode-pack additions, you
could just uninstall that and leave the evil package there.
So the broader point here is that I'm trying to make package.el
packages first class citizens in Emacs Live, no matter how you want
to consume them.
I did have to change some load order stuff around to make it work in
my fork. But I don't remember enough of the details to offer specific
advice on the problem you're currently facing.
Post by Chas EmerickTo the original query, I guess I'm looking for where I should put
local environment configuration such that it is truly loaded after
*everything* else in the system. Secondarily, I'm curious as to why
`eval-after-load` doesn't work, as my understanding is that it
exists solely to resolve this problem of undefined package load order.
Thanks,
- Chas
Post by Wes MorganI agree with you Chas, it would be better to use the existing
package system. I have a work-in-progress port of the whole Emacs
Live system to use packages (and turn live packs into package
https://github.com/cap10morgan/emacs-live/tree/live-packages
I still need to finish converting it to use package dependencies
everywhere and update it to 1.0-BETA-23.
But if others want to see a package.el-based Emacs Live, I'd love
to get some testing, feedback, and/or help with that port.
- Wes
Thanks for that. But, I'd rather consume things like evil via the
existing package system, since that is likely to remain the most
stable / well-maintained compared to a "port" to a pack-style config.
This response and the existence of an evil pack prompts me to ask
a more general question: is emacs-live not intended to
interoperate with package.el-obtained libraries? i.e. is it
expected that any elisp libraries be consumed as packs / git
submodules exclusively?
Thanks,
- Chas
Post by Julian Birchhttps://github.com/siancu/evilmode-pack
I hope this helps. I could get it running, but found it got rather
confused if you kept hitting ESC.
Julian
Hi all,
I am attempting to get evil-mode on by default at startup. Just
putting `(require 'evil) (evil-mode 1)` (along with other
evil-related config) in my ~/.live-packs/chas-pack/init.el is
insufficient, as it seems that evil is not yet loaded when that
file is evaluated, and so an error occurs on startup. I installed
evil via MELPA, so it's in ~/.emacs.d/elpa; it looks like all
packages installed thusly are loaded after the emacs-live startup?
(eval-after-load 'evil '(live-load-config-file "evil.el"))
Where ~/.live-packs/chas-pack/config/evil.el contains the
requisite require/evil-mode calls + configuration. This
eliminates the error, but evil.el is never loaded; I need to open
it and eval-buffer explicitly to turn on evil and get my
configuration loaded.
Help?
Thanks,
- Chas
--
You received this message because you are subscribed to the Google
Groups "Emacs Live" group.
To unsubscribe from this group and stop receiving emails from it,
<javascript:_e({}, 'cvml',
For more options, visit https://groups.google.com/groups/opt_out.
--
Sent from an iPhone, please excuse brevity and typos.
--
You received this message because you are subscribed to the Google
Groups "Emacs Live" group.
To unsubscribe from this group and stop receiving emails from it, send
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "Emacs Live" group.
To unsubscribe from this group and stop receiving emails from it,
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google
Groups "Emacs Live" group.
To unsubscribe from this group and stop receiving emails from it,
For more options, visit https://groups.google.com/groups/opt_out.
--
You received this message because you are subscribed to the Google Groups "Emacs Live" group.
To unsubscribe from this group and stop receiving emails from it, send an email to emacs-live+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.