HTTPS clone URL
Subversion checkout URL
Clone this wiki locally
Welcome to the el-get wiki!
The mailing list archive is at gmane.emacs.el-get.devel. You can subscribe by sending an email to
An el-get recipe should make code available on the local machine as though it were packaged with Emacs. With very few exceptions, Emacs' own packages:
- Are loaded only on-demand via
- Do not make features (such as minor mode and color theme) globally active;
- Do make features globally available (e.g. via autoloads);
- Do make features selectively active (e.g., activating a major mode based on filename) when that reflects popular practice.
If a package does not follow these principles "by itself", please try to get the package maintainer to fix that before submitting a recipe that attempts to compensate. If you can't get the package maintainer to make adjustments in a timely fashion, the following compensations in recipes are allowed and encouraged:
- Major modes can be added to
auto-mode-alistfor commonly-used, unambigous file patterns.
By default, el-get automatically compiles autoloads for any package written with autoload cookies into a file that's loaded at startup. However, recipes for packages that generate their own autoload files at installation time should disable automatic autoloads and eagerly load that file instead. For example, the nognus recipe contains
:autoloads nil and
:features gnus-load. Aside from cases like this, there should almost never be a reason to use
:features (or, as a last resort,
Having recipes that work somewhere is definitely a higher priority than making sure that recipes work everywhere. That said, portable recipes are encouraged, and it's often straightforward to make recipes completely portable. Recipes for simple packages will often be portable "automagically," if you just let el-get do what it does naturally: byte-compile the files, put them in the load path, prepare autoloads, make
.texi files accessible to the `M-x info' system, etc.
When installation is more complex, it's helpful to use Emacs itself as a portability layer, and especially to avoid using
make (often not present on Windows) if possible. In in these cases, a Makefile is often just a thin layer over some invocations of Emacs anyway, which makes it relatively easy to skip
make altogether and invoke Emacs directly from your recipe. You can get the full path to Emacs itself by using the variable
el-get-emacs in a recipe's
:build field. The following recipe shows how you can use
el-get-emacs to invoke Emacs twice in a
(:name apel :type cvs :module "apel" :url ":pserver:email@example.com:/cvs/root" :build (mapcar (lambda (target) (list el-get-emacs (split-string "-batch -q -no-site-file -l APEL-MK -f") target "prefix" "site-lisp" "site-lisp")) '("compile-apel" "install-apel")) :load-path ("site-lisp/apel" "site-lisp/emu"))