Pairing emacs-live with evil

469 views
Skip to first unread message

Chas Emerick

unread,
Oct 7, 2013, 6:48:21 AM10/7/13
to emacs...@googlegroups.com
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?

To work around this lifecycle issue, I attempted:

    (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

Julian Birch

unread,
Oct 7, 2013, 7:49:42 AM10/7/13
to emacs...@googlegroups.com
Hi, Stelian Iancu got it working as a separate pack.  He put it here:  https://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
--
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+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


--
Sent from an iPhone, please excuse brevity and typos.

Chas Emerick

unread,
Oct 7, 2013, 8:32:28 AM10/7/13
to emacs...@googlegroups.com
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
> <javascript:_e({}, 'cvml',
> 'emacs-live%2Bunsu...@googlegroups.com');>.

Wes Morgan

unread,
Oct 7, 2013, 9:34:57 AM10/7/13
to emacs...@googlegroups.com
I 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 dependencies + config files). That lives here: 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
signature.asc

Chas Emerick

unread,
Oct 7, 2013, 9:45:20 AM10/7/13
to emacs...@googlegroups.com
To 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).

To 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

Wes Morgan

unread,
Oct 7, 2013, 9:53:48 AM10/7/13
to emacs...@googlegroups.com

On Oct 7, 2013, at 7:45 AM, Chas Emerick <ch...@cemerick.com> wrote:

> To 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.
signature.asc

Sam Aaron

unread,
Oct 7, 2013, 10:10:12 AM10/7/13
to emacs...@googlegroups.com
Howdy 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

Chas Emerick

unread,
Oct 7, 2013, 11:09:57 AM10/7/13
to emacs...@googlegroups.com
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

Sam Aaron

unread,
Oct 7, 2013, 11:20:41 AM10/7/13
to emacs...@googlegroups.com
Hey Chas,

using an after-init-hook sounds great - happy to consider a pull request :-)

Sam

---
http://sam.aaron.name

Chas Emerick

unread,
Oct 7, 2013, 11:50:28 AM10/7/13
to emacs...@googlegroups.com
Here's one: https://github.com/overtone/emacs-live/pull/136

Maybe others can give it a try? I am a complete novice when it comes
to elisp, so some sanity checking wouldn't hurt.

Thanks,

- Chas

andrea.r...@gmail.com

unread,
Feb 17, 2017, 11:24:23 AM2/17/17
to Emacs Live
Hello!

I am still very very happy with emacs live and kind of trying to revamp old but good ideas. I so like Was idea, as it would allow Emacs Live to work in mixed mode, taking packs both from elpa and custom repositories.

To be fair I found quite useful for my mental (in)sanity to go to a submodule and checkout a commit that did not break and I would like to keep this option available along with the possibility to add packages from elpa.

For example cider in my fork is always on master.

I am willing to experiment a bit on this, thanks!
Reply all
Reply to author
Forward
0 new messages