2018-01-24 10:55:05 +08:00
|
|
|
|
This is el-get.info, produced by makeinfo version 4.13 from el-get.texi.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
INFO-DIR-SECTION Emacs
|
|
|
|
|
START-INFO-DIR-ENTRY
|
|
|
|
|
* El-Get: (el-get). Using el-get to manage your Emacs Extensions.
|
|
|
|
|
END-INFO-DIR-ENTRY
|
|
|
|
|
|
2013-05-15 20:56:20 +08:00
|
|
|
|
Copyright (C) 2010, 2011, 2012, 2013 Dimitri Fontaine.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE
|
|
|
|
|
Version 2, December 2004
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
Copyright (C) 2004 Sam Hocevar <sam@hocevar.net>
|
|
|
|
|
|
|
|
|
|
Everyone is permitted to copy and distribute verbatim or modified
|
|
|
|
|
copies of this license document, and changing it is allowed as long
|
|
|
|
|
as the name is changed.
|
|
|
|
|
|
|
|
|
|
DO WHAT THE FUCK YOU WANT TO PUBLIC LICENSE TERMS AND
|
|
|
|
|
CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
|
|
|
|
|
|
|
|
|
|
0. You just DO WHAT THE FUCK YOU WANT TO.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Top, Next: Introduction, Up: (dir)
|
|
|
|
|
|
|
|
|
|
El-Get User Manual
|
|
|
|
|
******************
|
|
|
|
|
|
|
|
|
|
El-Get is an Emacs Extension manager that allows you to install, update
|
|
|
|
|
and remove external Emacs Lisp extensions. More importantly, El-Get
|
|
|
|
|
will care about initializing installed extensions for you at Emacs
|
|
|
|
|
Startup.
|
|
|
|
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
|
|
|
|
* Introduction::
|
|
|
|
|
* Acknowledgments::
|
|
|
|
|
* Glossary::
|
|
|
|
|
* Installing::
|
|
|
|
|
* Usage::
|
|
|
|
|
* Setup::
|
|
|
|
|
* User Init::
|
|
|
|
|
* Recipes::
|
|
|
|
|
* Authoring Recipes::
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Introduction, Next: Acknowledgments, Prev: Top, Up: Top
|
|
|
|
|
|
|
|
|
|
1 Introduction
|
|
|
|
|
**************
|
|
|
|
|
|
|
|
|
|
El-Get allows you to install and manage Emacs Lisp code for Emacs. It
|
|
|
|
|
supports lots of differents types of sources and is able to install
|
|
|
|
|
them, update them and remove them, and more importantly it will init
|
|
|
|
|
them for you.
|
|
|
|
|
|
|
|
|
|
That means it will `require' the `features' you need, `load' the
|
|
|
|
|
necessary files, set the `Info' paths so that `C-h i' shows the new
|
|
|
|
|
documentation you now depend on, and finally call your own `post-init'
|
|
|
|
|
function for you to setup the extension. Or call it a package.
|
|
|
|
|
|
|
|
|
|
El-Get Version String (`M-x el-get-version') are now inspired by how
|
|
|
|
|
Emacs itself numbers its versions. First is the major version number,
|
|
|
|
|
then a dot, then the minor version number. The minor version number is
|
2013-04-25 14:28:44 +08:00
|
|
|
|
0 when still developing the next major version. So 3.0 is a developer
|
2012-07-18 23:51:15 +08:00
|
|
|
|
release while 3.1 is a stable release.
|
|
|
|
|
|
|
|
|
|
Please note that this versioning policy has been picked while backing
|
|
|
|
|
1.2~dev, so 1.0 was a "stable" release in fact. Ah, history.
|
|
|
|
|
|
2014-01-12 00:48:33 +08:00
|
|
|
|
El-Get is considered to now have reached a very stable state where it
|
|
|
|
|
only receives bug fixes, code refactoring, and new recipes. The current
|
|
|
|
|
version is now 5.1, which is stable, and maintained in the "master" git
|
|
|
|
|
branch.
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Acknowledgments, Next: Glossary, Prev: Introduction, Up: Top
|
|
|
|
|
|
|
|
|
|
2 Acknowledgments
|
|
|
|
|
*****************
|
|
|
|
|
|
2012-07-31 01:33:55 +08:00
|
|
|
|
Dimitri Fontaine started the whole project and still manages the
|
|
|
|
|
releases, and sometimes even contribute code and documentation.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
Julien Danjou has been a contributor since very early days, about the
|
|
|
|
|
first beta tester of the idea, before we really knew how much to
|
|
|
|
|
achieve.
|
|
|
|
|
|
2012-07-31 01:33:55 +08:00
|
|
|
|
Ryan C. Thompson joined and commented some issues, began contributing
|
|
|
|
|
and quickly became top-level and most active contributor to the
|
|
|
|
|
project, getting a commit bit and some management duties. He manages
|
|
|
|
|
tests and issues on github as much as he can spares time to El-Get.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
Dave Abrahams contributed lots of code and efforts to make things
|
2014-05-04 03:15:08 +08:00
|
|
|
|
right™. He's still using El-Get, but decided to retire from the project.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-31 01:33:55 +08:00
|
|
|
|
Lots of people (more than we can list here) did contribute to El-Get
|
2012-07-18 23:51:15 +08:00
|
|
|
|
either recipes, bug fixes or ideas to implement, often with code. That
|
|
|
|
|
builds up an awesome community, thanks guys!
|
|
|
|
|
|
2014-01-12 00:54:18 +08:00
|
|
|
|
~/dev/emacs/el-get git --no-pager shortlog -n -s | wc -l
|
|
|
|
|
258
|
|
|
|
|
~/dev/emacs/el-get git --no-pager shortlog -n -s | head -15
|
|
|
|
|
1058 Dimitri Fontaine
|
|
|
|
|
359 Ryan C. Thompson
|
|
|
|
|
159 Julien Danjou
|
2012-07-31 01:33:55 +08:00
|
|
|
|
110 Dave Abrahams
|
2014-01-12 00:54:18 +08:00
|
|
|
|
97 Sébastien Gross
|
|
|
|
|
94 Takafumi Arakaki
|
|
|
|
|
92 yagnesh రాఘవ
|
|
|
|
|
86 Ryan Thompson
|
|
|
|
|
73 Rüdiger Sonderfeld
|
|
|
|
|
62 David Holm
|
|
|
|
|
56 Yakkala Yagnesh Raghava
|
|
|
|
|
48 Alex Ott
|
|
|
|
|
40 Shigenobu Nishikawa
|
|
|
|
|
35 Damien Cassou
|
|
|
|
|
23 Reuben Thomas
|
2012-07-31 01:33:55 +08:00
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Glossary, Next: Installing, Prev: Acknowledgments, Up: Top
|
|
|
|
|
|
|
|
|
|
3 Glossary
|
|
|
|
|
**********
|
|
|
|
|
|
|
|
|
|
Autoload
|
|
|
|
|
Delay loading a package definition until its first use.
|
|
|
|
|
|
|
|
|
|
Build
|
|
|
|
|
Action that happens at *Note Glossary - Install::, and *Note
|
|
|
|
|
Glossary - Update::. Packages might skip any `build' step
|
|
|
|
|
entirely. When given, the build step allows to run system level
|
|
|
|
|
tools (think `make'), often to produce to derivative files.
|
|
|
|
|
|
|
|
|
|
Byte-Compile
|
|
|
|
|
Action to compile Emacs Lisp files so that loading them is faster.
|
|
|
|
|
El-Get is able to automatically manage that step at install and
|
|
|
|
|
update time so that init time is faster, see *Note Glossary -
|
|
|
|
|
Init::.
|
|
|
|
|
|
|
|
|
|
Dependency
|
|
|
|
|
Any El-Get package can depend on some others. At install time,
|
|
|
|
|
El-Get will make sure all dependant packages are installed first.
|
|
|
|
|
At init time, same thing will happen. Dependency management is
|
|
|
|
|
solved with a topological sort so that if you install a package
|
|
|
|
|
`a' that depends on a package `b' that depends on a package `c',
|
|
|
|
|
El-Get will install `c' then `b' then `a'.
|
|
|
|
|
|
|
|
|
|
Init
|
|
|
|
|
When you start Emacs you want your packages to get setup and ready
|
|
|
|
|
to serve whatever usage you have of this advanced Operating
|
|
|
|
|
System. El-Get calls this setup step the `init' and will care
|
|
|
|
|
about initializing your packages automatically given a *Note
|
|
|
|
|
Glossary - Recipe::.
|
|
|
|
|
|
|
|
|
|
Install
|
|
|
|
|
El-Get install a package by fetching its sources as described in
|
|
|
|
|
the package recipe, then running the build steps if the recipe
|
|
|
|
|
contains such.
|
|
|
|
|
|
|
|
|
|
Method
|
|
|
|
|
An El-Get method is a backend code providing facilities to fetch,
|
|
|
|
|
install, update and remove external code. El-Get currently
|
|
|
|
|
implements methods that targets `apt-get', `brew', `builtin',
|
|
|
|
|
`bzr', `cvs', `darcs', `elpa', `emacsmirror', `emacswiki', `fink',
|
|
|
|
|
`fossil', `git' and `git-svn', `github' `github-tar' and
|
2014-01-12 00:48:33 +08:00
|
|
|
|
`github-zip', `go', `hg', `http' `http-tar' and `http-zip',
|
|
|
|
|
`pacman' and `svn'.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
Notification
|
|
|
|
|
El-Get notifies its user when a package is done installing,
|
|
|
|
|
updating or removing. It knows how to use several system level
|
|
|
|
|
notification facilities, such as `DBUS' or `growl'.
|
|
|
|
|
|
|
|
|
|
Package
|
|
|
|
|
A package is what El-Get manages for you. It's a set of Emacs Lisp
|
|
|
|
|
files (possible a set of a single file, possibly with some Info
|
|
|
|
|
documentation and build scripts, etc) that El-Get knows how to
|
|
|
|
|
fetch and install, update and remove, and init at Emacs Startup.
|
|
|
|
|
|
|
|
|
|
Recipe
|
|
|
|
|
An El-Get recipe describes a package in terms that allow El-Get to
|
|
|
|
|
provide its features against that package. It's easy enough to
|
|
|
|
|
write recipes, and fun to share them!
|
|
|
|
|
|
|
|
|
|
Remove
|
|
|
|
|
El-Get removes a package by simple removing the directory where the
|
|
|
|
|
package is installed. If you want the features of the package to
|
|
|
|
|
get unloaded, most often the easier way to do that is to restart
|
|
|
|
|
Emacs.
|
|
|
|
|
|
|
|
|
|
Status
|
|
|
|
|
One of `available', `installed', `required' or `removed'. When
|
|
|
|
|
El-Get is asked to install a package, the status is set to
|
|
|
|
|
`required' before to fetch and build it, so that in case of error
|
|
|
|
|
the system knows to try installing again.
|
|
|
|
|
|
|
|
|
|
Update
|
|
|
|
|
El-Get updates a package in different ways, depending on the
|
|
|
|
|
package type and the associated method. In some cases it's not
|
|
|
|
|
possible to update a package, like when it switched from `svn' to
|
|
|
|
|
`git' for example.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Installing, Next: Usage, Prev: Glossary, Up: Top
|
|
|
|
|
|
|
|
|
|
4 Installing
|
|
|
|
|
************
|
|
|
|
|
|
|
|
|
|
El-Get comes with a `*scratch*'-installer. Ideally you would install
|
|
|
|
|
El-Get with El-Get itself, but I couldn't figure out how to do that, so
|
|
|
|
|
instead you have to copy and paste the following code into your
|
|
|
|
|
`*scratch*' buffer and evaluate it:
|
|
|
|
|
|
|
|
|
|
;; So the idea is that you copy/paste this code into your *scratch* buffer,
|
|
|
|
|
;; hit C-j, and you have a working el-get.
|
|
|
|
|
(url-retrieve
|
|
|
|
|
"https://raw.github.com/dimitri/el-get/master/el-get-install.el"
|
|
|
|
|
(lambda (s)
|
|
|
|
|
(goto-char (point-max))
|
|
|
|
|
(eval-print-last-sexp)))
|
|
|
|
|
|
|
|
|
|
To evaluate that code, you place the point at the end of the text
|
|
|
|
|
block (just after the last closing paren) and you type `C-j'.
|
|
|
|
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
2015-11-18 00:15:14 +08:00
|
|
|
|
* Install the developer version::
|
2012-07-18 23:51:15 +08:00
|
|
|
|
* Skip Emacswiki recipes when installing::
|
2018-01-24 10:55:05 +08:00
|
|
|
|
* Shallow clone when installing::
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
2015-11-18 00:15:14 +08:00
|
|
|
|
File: el-get.info, Node: Install the developer version, Next: Skip Emacswiki recipes when installing, Up: Installing
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2015-11-18 00:15:14 +08:00
|
|
|
|
4.1 Developer version
|
2018-01-24 10:55:05 +08:00
|
|
|
|
=====================
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
The lazy installer uses the default `el-get-install.el' file which
|
|
|
|
|
targets the `stable' branch. To install El-Get directly on the
|
|
|
|
|
`master' branch, summon the `el-get-master-branch' variable into
|
|
|
|
|
existence:
|
|
|
|
|
|
|
|
|
|
;; So the idea is that you copy/paste this code into your *scratch* buffer,
|
2015-11-18 00:15:14 +08:00
|
|
|
|
;; hit C-j, and you have a working developer edition of el-get.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
(url-retrieve
|
|
|
|
|
"https://raw.github.com/dimitri/el-get/master/el-get-install.el"
|
|
|
|
|
(lambda (s)
|
|
|
|
|
(let (el-get-master-branch)
|
|
|
|
|
(goto-char (point-max))
|
|
|
|
|
(eval-print-last-sexp))))
|
|
|
|
|
|
|
|
|
|
|
2018-01-24 10:55:05 +08:00
|
|
|
|
File: el-get.info, Node: Skip Emacswiki recipes when installing, Next: Shallow clone when installing, Prev: Install the developer version, Up: Installing
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
4.2 Skip Emacswiki recipes when installing
|
|
|
|
|
==========================================
|
|
|
|
|
|
|
|
|
|
The installer will fetch from emacswiki all the recipe available there
|
|
|
|
|
and install a local copy of those in your system automatically. Should
|
|
|
|
|
you want to disable that feature, the following snippet is showing how
|
|
|
|
|
to:
|
|
|
|
|
|
|
|
|
|
;; So the idea is that you copy/paste this code into your *scratch* buffer,
|
|
|
|
|
;; hit C-j, and you have a working el-get (without emacswiki automatic
|
|
|
|
|
;; recipes).
|
|
|
|
|
(url-retrieve
|
|
|
|
|
"https://raw.github.com/dimitri/el-get/master/el-get-install.el"
|
|
|
|
|
(lambda (s)
|
|
|
|
|
(let (el-get-install-skip-emacswiki-recipes)
|
|
|
|
|
(goto-char (point-max))
|
|
|
|
|
(eval-print-last-sexp))))
|
|
|
|
|
|
2018-01-24 10:55:05 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Shallow clone when installing, Prev: Skip Emacswiki recipes when installing, Up: Installing
|
|
|
|
|
|
|
|
|
|
4.3 Shallow clone when installing
|
|
|
|
|
=================================
|
|
|
|
|
|
|
|
|
|
`--depth 1'
|
|
|
|
|
|
|
|
|
|
Should you want to run `git-clone' with `--depth 1' when installing
|
|
|
|
|
El-Get itself, the following snippet is showing how to:
|
|
|
|
|
|
|
|
|
|
(url-retrieve
|
|
|
|
|
"https://raw.github.com/dimitri/el-get/master/el-get-install.el"
|
|
|
|
|
(lambda (s)
|
|
|
|
|
(let (el-get-install-shallow-clone)
|
|
|
|
|
(goto-char (point-max))
|
|
|
|
|
(eval-print-last-sexp))))
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Usage, Next: Setup, Prev: Installing, Up: Top
|
|
|
|
|
|
|
|
|
|
5 Usage
|
|
|
|
|
*******
|
|
|
|
|
|
|
|
|
|
Now that El-Get is installed, simply use `M-x el-get-install' and pick
|
|
|
|
|
whatever package you need.
|
|
|
|
|
|
|
|
|
|
Here's a list of commands provided by El-Get:
|
|
|
|
|
|
|
|
|
|
`el-get-list-packages'
|
|
|
|
|
List all available packages with their names, *Note Glossary -
|
|
|
|
|
Status::, and description. Name and description are taken from the
|
|
|
|
|
recipe file of the package.
|
|
|
|
|
|
|
|
|
|
You can find which recipe file is used for a given package using
|
|
|
|
|
`el-get-find-recipe-file' or `el-get-describe'.
|
|
|
|
|
|
|
|
|
|
`el-get-describe'
|
|
|
|
|
Offers a full text description of a package with buttons to
|
|
|
|
|
install, remove and update, and with the recipe content.
|
|
|
|
|
|
|
|
|
|
`el-get-find-recipe-file'
|
|
|
|
|
Find the recipe file for given recipe, prompted.
|
|
|
|
|
|
|
|
|
|
`el-get-install'
|
|
|
|
|
Install given package, as prompted.
|
|
|
|
|
|
|
|
|
|
`el-get-init'
|
|
|
|
|
Initialize given package, as prompted. If some user code is setup
|
|
|
|
|
to be run at initialisation, it will get run by this command. See
|
|
|
|
|
*Note User Init::.
|
|
|
|
|
|
|
|
|
|
`el-get-update'
|
|
|
|
|
Update a given package, as prompted. In some cases a straight
|
|
|
|
|
update is not possible (recipe switched from CVS to git is a common
|
|
|
|
|
reason). El-Get will try and detect such cases and do
|
|
|
|
|
`el-get-remove' then `el-get-install' if necessary.
|
|
|
|
|
|
|
|
|
|
Please realise that updating packages might break your current
|
|
|
|
|
package setup and that you will have to revisit your setup
|
|
|
|
|
accordingly.
|
|
|
|
|
|
|
|
|
|
`el-get-remove'
|
|
|
|
|
Remove given package, as prompted.
|
|
|
|
|
|
2012-07-24 02:27:13 +08:00
|
|
|
|
`el-get-self-update'
|
|
|
|
|
Update El-Get itself, and force that update to be synchronous. That
|
|
|
|
|
allows to make sure you're not updating El-Get code while trying to
|
|
|
|
|
update or install some other package at the same time.
|
|
|
|
|
|
|
|
|
|
`el-get-update-all'
|
|
|
|
|
Will update all packages that have the `installed' status in your
|
|
|
|
|
status file. Before the update you will be prompted for
|
|
|
|
|
confirmation that you wish to proceed.
|
|
|
|
|
|
|
|
|
|
Beware that using this function can lead to hours of settings
|
|
|
|
|
review: more often than not updating a package requires some
|
|
|
|
|
adjustments to your setup. Updating all of them at once will
|
|
|
|
|
require reviewing almost all your setup.
|
|
|
|
|
|
|
|
|
|
`el-get-reload'
|
|
|
|
|
Reload the given package files. Happens automatically at update
|
|
|
|
|
time too.
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Setup, Next: User Init, Prev: Usage, Up: Top
|
|
|
|
|
|
|
|
|
|
6 Setup
|
|
|
|
|
*******
|
|
|
|
|
|
|
|
|
|
El-Get setup can be very simple or arbitrarily complex. This chapter
|
|
|
|
|
explains how to do the very basic setup, which allow for using `M-x
|
|
|
|
|
el-get-install' and friends, then how to get a more involved setup.
|
|
|
|
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
|
|
|
|
* Basic Setup::
|
|
|
|
|
* The el-get function::
|
|
|
|
|
* Distributed Setup::
|
2014-12-08 08:49:36 +08:00
|
|
|
|
* The el-get-bundle macro::
|
2012-07-24 02:27:13 +08:00
|
|
|
|
* Setup Customization::
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Basic Setup, Next: The el-get function, Up: Setup
|
|
|
|
|
|
|
|
|
|
6.1 Basic Setup
|
|
|
|
|
===============
|
|
|
|
|
|
|
|
|
|
You can then arrange to have El-Get part of your setup, so that at next
|
|
|
|
|
emacs startup the installed packages are initialized.
|
|
|
|
|
|
2022-12-31 20:28:53 +08:00
|
|
|
|
(add-to-list 'load-path (expand-file-name "el-get/el-get" user-emacs-directory))
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
(unless (require 'el-get nil t)
|
|
|
|
|
(with-current-buffer
|
|
|
|
|
(url-retrieve-synchronously
|
|
|
|
|
"https://raw.github.com/dimitri/el-get/master/el-get-install.el")
|
|
|
|
|
(goto-char (point-max))
|
|
|
|
|
(eval-print-last-sexp)))
|
|
|
|
|
|
2013-05-15 20:56:20 +08:00
|
|
|
|
(add-to-list 'el-get-recipe-path "~/.emacs.d/el-get-user/recipes")
|
2012-07-18 23:51:15 +08:00
|
|
|
|
(el-get 'sync)
|
|
|
|
|
|
|
|
|
|
The `el-get' command will check that each and every package is
|
|
|
|
|
installed on your system (in `el-get-dir' and if that's not the case,
|
|
|
|
|
it will actually install it. Then, it will init the packages: that
|
|
|
|
|
means caring about the `load-path', the `Info-directory-list' (and dir
|
|
|
|
|
texinfo menu building) the loading of the emacs-lisp files, and finally
|
|
|
|
|
it will require the features or eval the package `autoloads'.
|
|
|
|
|
|
|
|
|
|
This usage is pretty simple to setup and use, but fails to cater with
|
|
|
|
|
more complex setups involving multiple deployments (home and work
|
|
|
|
|
laptop would be a classic example). El-Get fully supports that
|
|
|
|
|
distributed setup, though, and this chapter explain how.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: The el-get function, Next: Distributed Setup, Prev: Basic Setup, Up: Setup
|
|
|
|
|
|
|
|
|
|
6.2 The el-get function
|
|
|
|
|
=======================
|
|
|
|
|
|
|
|
|
|
Ensure that packages have been downloaded once and init them as needed.
|
|
|
|
|
|
|
|
|
|
This will not update the sources by using `apt-get install' or `git
|
|
|
|
|
pull', but it will ensure that:
|
|
|
|
|
|
|
|
|
|
* the packages have been installed
|
|
|
|
|
|
|
|
|
|
* load-path is set so their elisp files can be found
|
|
|
|
|
|
|
|
|
|
* Info-directory-list is set so their info files can be found
|
|
|
|
|
|
|
|
|
|
* Autoloads have been prepared and evaluated for each package
|
|
|
|
|
|
|
|
|
|
* Any post-installation setup (e.g. `(require 'feature)') happens
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
When SYNC is `nil' (the default), all installations run
|
|
|
|
|
concurrently, in the background.
|
|
|
|
|
|
|
|
|
|
When SYNC is `sync', each package will be installed synchronously,
|
|
|
|
|
and any error will stop it all.
|
|
|
|
|
|
|
|
|
|
Please note that the `el-get-init' part of `el-get' is always done
|
2012-07-31 01:33:55 +08:00
|
|
|
|
synchronously. There's `byte-compile' support though, and the packages
|
|
|
|
|
you use are welcome to use `autoload' too. You can also force your
|
|
|
|
|
setup to be loaded lazily with the `el-get-is-lazy' variable.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
`PACKAGES' is expected to be a list of packages you want to install
|
|
|
|
|
or init. When `PACKAGES' is omited (the default), the list of already
|
|
|
|
|
installed packages is considered.
|
|
|
|
|
|
|
|
|
|
|
2014-12-08 08:49:36 +08:00
|
|
|
|
File: el-get.info, Node: Distributed Setup, Next: The el-get-bundle macro, Prev: The el-get function, Up: Setup
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
6.3 Distributed Setup
|
|
|
|
|
=====================
|
|
|
|
|
|
|
|
|
|
When you are sharing your emacs setup between several machines (work
|
|
|
|
|
and home destops, laptop, etc); it's usual to manage your `.emacs.d'
|
2012-10-01 05:53:18 +08:00
|
|
|
|
setup in a distributed repository (such as `git'). El-Get then provides
|
|
|
|
|
an easy canonical list of packages you depend on to run emacs, and this
|
2013-05-15 20:56:20 +08:00
|
|
|
|
documentation is usable as-is. It is recommended that you not store the
|
|
|
|
|
El-Get tree in git, however; to prevent this, so you can add a pattern
|
|
|
|
|
`/el-get' to `.emacs.d/.gitignore'.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2022-12-31 20:28:53 +08:00
|
|
|
|
(add-to-list 'load-path (expand-file-name "el-get/el-get" user-emacs-directory))
|
2012-07-18 23:51:15 +08:00
|
|
|
|
(require 'el-get)
|
|
|
|
|
|
|
|
|
|
;; local sources
|
|
|
|
|
(setq el-get-sources
|
|
|
|
|
'((:name magit
|
|
|
|
|
:after (global-set-key (kbd "C-x C-z") 'magit-status))
|
|
|
|
|
|
|
|
|
|
(:name asciidoc
|
|
|
|
|
:type elpa
|
|
|
|
|
:after (progn
|
|
|
|
|
(autoload 'doc-mode "doc-mode" nil t)
|
|
|
|
|
(add-to-list 'auto-mode-alist '("\\.adoc$" . doc-mode))
|
|
|
|
|
(add-hook 'doc-mode-hook
|
|
|
|
|
'(lambda ()
|
|
|
|
|
(turn-on-auto-fill)
|
|
|
|
|
(require 'asciidoc)))))
|
|
|
|
|
|
|
|
|
|
(:name lisppaste :type elpa)
|
|
|
|
|
|
|
|
|
|
(:name emacs-goodies-el :type apt-get)))
|
|
|
|
|
|
|
|
|
|
(setq my-packages
|
|
|
|
|
(append
|
|
|
|
|
'(cssh el-get switch-window vkill google-maps nxhtml xcscope yasnippet)
|
|
|
|
|
(mapcar 'el-get-source-name el-get-sources)))
|
|
|
|
|
|
|
|
|
|
(el-get 'sync my-packages)
|
|
|
|
|
|
2012-10-01 14:15:24 +08:00
|
|
|
|
Please note that when you unreference a package from `my-packages',
|
|
|
|
|
it remains locally installed.
|
|
|
|
|
|
2012-10-01 05:53:18 +08:00
|
|
|
|
Going one step further with the idea of a canonical list, el-get
|
|
|
|
|
provides the command `el-get-cleanup', which will remove all packages
|
2012-10-01 14:15:24 +08:00
|
|
|
|
absent from `my-packages'. This allows, in effect, to put under version
|
2012-10-01 05:53:18 +08:00
|
|
|
|
control only the user init file, instead of the whole `.emacs.d'
|
2012-10-01 14:15:24 +08:00
|
|
|
|
directory, and still enjoy a truly portable emacs configuration.
|
|
|
|
|
|
|
|
|
|
In the code example above, replace the last line with the following:
|
2012-10-01 05:53:18 +08:00
|
|
|
|
|
|
|
|
|
(el-get-cleanup my-packages)
|
2012-10-01 14:15:24 +08:00
|
|
|
|
(el-get 'sync my-packages)
|
2012-10-01 05:53:18 +08:00
|
|
|
|
|
2014-12-08 08:49:36 +08:00
|
|
|
|
You can also use `el-get-bundle' macro as a syntactic sugar to
|
|
|
|
|
specify a local source to install. With this macro, nothing other than
|
|
|
|
|
specified packages is installed.
|
|
|
|
|
|
2022-12-31 20:28:53 +08:00
|
|
|
|
(add-to-list 'load-path (expand-file-name "el-get/el-get" user-emacs-directory))
|
2014-12-08 08:49:36 +08:00
|
|
|
|
(require 'el-get)
|
|
|
|
|
|
|
|
|
|
;; packages from recipe files
|
|
|
|
|
(el-get 'sync
|
|
|
|
|
'(cssh el-get switch-window vkill google-maps nxhtml xcscope yasnippet))
|
|
|
|
|
|
|
|
|
|
;; local sources
|
|
|
|
|
(el-get-bundle magit
|
|
|
|
|
(global-set-key (kbd "C-x C-z") 'magit-status))
|
|
|
|
|
(el-get-bundle elpa:asciidoc
|
|
|
|
|
(autoload 'doc-mode "doc-mode" nil t)
|
|
|
|
|
(add-to-list 'auto-mode-alist '("\\.adoc$" . doc-mode))
|
|
|
|
|
(add-hook 'doc-mode-hook
|
|
|
|
|
'(lambda ()
|
|
|
|
|
(turn-on-auto-fill)
|
|
|
|
|
(require 'asciidoc))))
|
|
|
|
|
(el-get-bundle elpa:lisppaste)
|
|
|
|
|
(el-get-bundle apt-get:emacs-goodies-el)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: The el-get-bundle macro, Next: Setup Customization, Prev: Distributed Setup, Up: Setup
|
|
|
|
|
|
|
|
|
|
6.4 The el-get-bundle macro
|
|
|
|
|
===========================
|
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
The macro `el-get-bundle' is a syntactic sugar which allows you to tell
|
|
|
|
|
El-Get to install some package with a local source definition and
|
|
|
|
|
initialization code for the package. It is called in a form
|
|
|
|
|
`(el-get-bundle PACKAGE PROPERTIES CODE)', where PACKAGE specifies a
|
|
|
|
|
package name, PROPERTIES specifies a local recipe definition and CODE
|
|
|
|
|
specifies initialization code.
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
6.4.1 Just install some package
|
|
|
|
|
-------------------------------
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
To install a package whose source is already defined in a recipe file,
|
|
|
|
|
use `el-get-bundle' macro with the package name.
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
(el-get-bundle color-moccur)
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
This is essentially equivalent to the following code.
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
(el-get 'sync 'color-moccur)
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
6.4.2 Install some package with requiring it
|
|
|
|
|
--------------------------------------------
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
If you also want to `require' the package, use `el-get-bundle!' macro.
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
(el-get-bundle! color-moccur)
|
|
|
|
|
|
|
|
|
|
When the name of the feature you require is different from the
|
|
|
|
|
package name (the recipe name), use `FEATURE in PACKAGE' form.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle! yaicomplete in github:tarao/elisp)
|
|
|
|
|
|
|
|
|
|
If you wish to `require' more than one feature, then put them in a
|
|
|
|
|
`:features' property.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle github:tarao/elisp
|
|
|
|
|
:features (yaicomplete mode-line-color))
|
|
|
|
|
|
|
|
|
|
6.4.3 Install some package and configure it
|
|
|
|
|
-------------------------------------------
|
|
|
|
|
|
|
|
|
|
You can write initalization code after the package name.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle anything
|
|
|
|
|
(global-set-key (kbd "C-x b") #'anything-for-files))
|
|
|
|
|
|
2015-01-06 09:12:15 +08:00
|
|
|
|
You can provide multiple initialization code for a single package by
|
|
|
|
|
writing `el-get-bundle' macro call may times. Each initialization code
|
|
|
|
|
is evaluated when the corresponding `el-get-bundle' macro call is
|
|
|
|
|
evaluated.
|
|
|
|
|
|
2014-12-12 13:19:59 +08:00
|
|
|
|
Initialization code is automatically compiled when they are evaluated
|
|
|
|
|
for the first time (after you modified the file enclosing the code) if
|
|
|
|
|
`el-get-bundle-byte-compile' is non-nil. The initialization code is
|
|
|
|
|
saved to a file in `el-get-bundle-init-directory' together with a
|
|
|
|
|
compiled version.
|
|
|
|
|
|
|
|
|
|
Note that you should not call functions or refer to variables defined
|
|
|
|
|
in the package if the package is going to be autoloaded. In such case,
|
|
|
|
|
you should use `with-eval-after-load' macro.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle anything
|
|
|
|
|
(global-set-key (kbd "C-x b") #'anything-for-files))
|
|
|
|
|
(with-eval-after-load 'anything
|
|
|
|
|
;; referring to `anything-map' requires "anything.el" to be loaded
|
|
|
|
|
(define-key anything-map (kbd "M-n") #'anything-next-source)
|
|
|
|
|
(define-key anything-map (kbd "M-p") #'anything-previous-source))
|
|
|
|
|
|
|
|
|
|
If you want the form passed to `with-eval-after-load' to be compiled
|
|
|
|
|
together with the initialization code, you can use tarao's
|
|
|
|
|
`with-eval-after-load-feature'
|
|
|
|
|
(https://github.com/tarao/with-eval-after-load-feature-el) instead or
|
|
|
|
|
you will get "reference to free variable" warnings during the
|
|
|
|
|
compilation.
|
|
|
|
|
|
2015-01-09 20:45:30 +08:00
|
|
|
|
(el-get-bundle with-eval-after-load-feature)
|
2014-12-12 13:19:59 +08:00
|
|
|
|
(el-get-bundle anything
|
|
|
|
|
(global-set-key (kbd "C-x b") #'anything-for-files)
|
|
|
|
|
(with-eval-after-load-feature 'anything
|
|
|
|
|
;; referring to `anything-map' requires "anything.el" to be loaded
|
|
|
|
|
(define-key anything-map (kbd "M-n") #'anything-next-source)
|
|
|
|
|
(define-key anything-map (kbd "M-p") #'anything-previous-source)))
|
|
|
|
|
|
|
|
|
|
6.4.4 Pass options to package source definitions
|
|
|
|
|
------------------------------------------------
|
|
|
|
|
|
|
|
|
|
If you want to override a package source definition in a recipe file or
|
|
|
|
|
define a new definition, you can pass a property list after the package
|
|
|
|
|
name.
|
|
|
|
|
|
|
|
|
|
For example, if you want to install `zenburn-theme' but want to use
|
|
|
|
|
other version than El-Get's default recipe, you can reuse the default
|
|
|
|
|
recipe with overriding `:url' option.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle zenburn-theme
|
|
|
|
|
:url "http://raw.github.com/bbatsov/zenburn-emacs/master/zenburn-theme.el"
|
|
|
|
|
(load-theme 'zenburn t))
|
|
|
|
|
|
|
|
|
|
If you want to define a new package source, then supply full options.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle! zlc
|
|
|
|
|
:type github :pkgname "mooz/emacs-zlc"
|
|
|
|
|
:description "Provides zsh like completion for minibuffer in Emacs"
|
|
|
|
|
:website "http://d.hatena.ne.jp/mooz/20101003/p1")
|
|
|
|
|
|
|
|
|
|
The property `:type' is required if the package source is already
|
|
|
|
|
defined but you don't reuse it. Otherwise, if the package source is not
|
|
|
|
|
defined yet, you can omit `:type' property as long as it can be guessed
|
|
|
|
|
from `:url'.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle! zlc :url "http://github.com/mooz/emacs-zlc.git")
|
|
|
|
|
;; equivalent to
|
|
|
|
|
;; (el-get-bundle! zlc :type git :url "http://github.com/mooz/emacs-zlc.git")
|
|
|
|
|
|
|
|
|
|
For further information on available properties for a recipe source,
|
|
|
|
|
*Note Recipe format::.
|
|
|
|
|
|
|
|
|
|
6.4.5 Syntax sugars for package source definitions
|
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
|
|
There are some ways to specify package source options by package name
|
|
|
|
|
modifiers. With these modifiers, you can omit `:type' property.
|
|
|
|
|
|
|
|
|
|
`OWNER/'
|
|
|
|
|
Specifies a github owner name.
|
|
|
|
|
|
|
|
|
|
`gist:ID'
|
|
|
|
|
Specifies a gist ID.
|
|
|
|
|
|
|
|
|
|
`TYPE:'
|
|
|
|
|
Specifies a type for the package.
|
|
|
|
|
|
|
|
|
|
(el-get-bundle tarao/tab-group)
|
|
|
|
|
;; equivalent to
|
|
|
|
|
;; (el-get-bundle tab-group :type github :pkgname "tarao/tab-group")
|
|
|
|
|
|
|
|
|
|
(el-get-bundle! gist:4362564:init-loader)
|
|
|
|
|
;; equivalent to
|
|
|
|
|
;; (el-get-bundle! init-loader :type git :url "http://gist.github.com/4362564.git")
|
|
|
|
|
|
|
|
|
|
(el-get-bundle elpa:undo-tree)
|
|
|
|
|
;; equivalent to
|
|
|
|
|
;; (el-get-bundle undo-tree :type elpa)
|
|
|
|
|
|
|
|
|
|
6.4.6 Customization
|
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
|
|
`el-get-bundle-init-dir'
|
|
|
|
|
Directory where a copy of initialization code specified in a
|
|
|
|
|
`el-get-bundle' macro call and its byte-compiled version are
|
|
|
|
|
saved. Defaults to `~/.emacs.d/el-get/bundle-init/'.
|
|
|
|
|
|
|
|
|
|
`el-get-bundle-byte-compile'
|
|
|
|
|
Whether to compile initialization code in a `el-get-bundle' macro
|
|
|
|
|
call. Defaults to `t'.
|
2014-12-08 08:49:36 +08:00
|
|
|
|
|
2012-07-24 02:27:13 +08:00
|
|
|
|
|
2014-12-08 08:49:36 +08:00
|
|
|
|
File: el-get.info, Node: Setup Customization, Prev: The el-get-bundle macro, Up: Setup
|
2012-07-24 02:27:13 +08:00
|
|
|
|
|
2014-12-08 08:49:36 +08:00
|
|
|
|
6.5 Setup Customization
|
2012-07-24 02:27:13 +08:00
|
|
|
|
=======================
|
|
|
|
|
|
|
|
|
|
Even though the defaults that are provided by El-Get provide all that
|
|
|
|
|
you need to get it working, there may be a reason to manually define
|
|
|
|
|
certain settings, particularly for portability.
|
|
|
|
|
|
|
|
|
|
`el-get-dir'
|
|
|
|
|
Path where packages are installed. Defaults to
|
|
|
|
|
`~/.emacs.d/el-get/'.
|
|
|
|
|
|
|
|
|
|
`el-get-install-dir'
|
|
|
|
|
Path for the `el-get' package. Defaults to
|
|
|
|
|
`~/.emacs.d/el-get/el-get'.
|
|
|
|
|
|
|
|
|
|
`el-get-install-branch'
|
|
|
|
|
If this is set, El-Get will be installed using the target
|
|
|
|
|
`branch'. This takes precedence over setting
|
|
|
|
|
`el-get-master-branch' in the installation settings, see *Note
|
|
|
|
|
Installing::.
|
|
|
|
|
|
|
|
|
|
`el-get-git-install-url'
|
|
|
|
|
Use this to specify your own fork of El-Get for installation.
|
|
|
|
|
|
|
|
|
|
`el-get-recipe-path-elpa'
|
|
|
|
|
This directory stores a local list of ELPA recipes.
|
|
|
|
|
`~/.emacs.d/el-get/el-get/recipes/elpa'
|
|
|
|
|
|
|
|
|
|
`el-get-recipe-path-emacswiki'
|
|
|
|
|
As above for ELPA, this directory stores a local list of emacswiki
|
|
|
|
|
recipes. Defaults to `~/.emacs.d/el-get/el-get/recipes/emacswiki/'.
|
|
|
|
|
|
2014-08-13 11:15:21 +08:00
|
|
|
|
`el-get-allow-insecure'
|
|
|
|
|
This determines whether or not El-Get will attempt to install
|
|
|
|
|
packages over insecure connections; setting it to nil
|
|
|
|
|
(recommended) will cause it to abort upon any install or update
|
|
|
|
|
operation which uses an unencrypted URL.
|
|
|
|
|
|
2012-07-24 02:27:13 +08:00
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: User Init, Next: Recipes, Prev: Setup, Up: Top
|
|
|
|
|
|
|
|
|
|
7 User Init
|
|
|
|
|
***********
|
|
|
|
|
|
|
|
|
|
The main task performed by El-Get is package initialization at Emacs
|
|
|
|
|
startup. It will care about all of them, their dependencies, and call
|
|
|
|
|
code provided by the recipe author. You can add your own setup code and
|
|
|
|
|
register it in a way that El-Get will evaluate it at the right time.
|
|
|
|
|
|
|
|
|
|
The package setup can either go into the `:after' property, or in a
|
|
|
|
|
file named `init-package.el' in `el-get-user-package-directory'. Any
|
|
|
|
|
such named file will get automatically loaded by El-Get at package init
|
|
|
|
|
time, if it exists.
|
|
|
|
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
|
|
|
|
* Before and After properties ::
|
|
|
|
|
* Initialization files::
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Before and After properties, Next: Initialization files, Up: User Init
|
|
|
|
|
|
|
|
|
|
7.1 Before and After properties
|
|
|
|
|
===============================
|
|
|
|
|
|
|
|
|
|
The `:before' and `:after' properties are evaluated by El-Get in the
|
|
|
|
|
package initialization sequence.
|
|
|
|
|
|
|
|
|
|
`:before'
|
|
|
|
|
This should be a lisp form to evaluate after both the
|
|
|
|
|
`Info-directory-list' and the `load-path' variables have been
|
|
|
|
|
taken care of, but before loading the package or any further
|
|
|
|
|
action from `el-get-init'. It will be run with the variable
|
|
|
|
|
`default-directory' set to the package directory.
|
|
|
|
|
|
|
|
|
|
`:after'
|
|
|
|
|
This should be a lisp form to evaluate after loading the package.
|
|
|
|
|
This function is registered for `eval-after-load' against the
|
|
|
|
|
recipe library by `el-get-init' once the `:load' and `:features'
|
|
|
|
|
have been setup. It will be run with the variable
|
|
|
|
|
`default-directory' set to the package directory.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Here's a couple of examples of package recipes that are using
|
|
|
|
|
`:before' and `:after' properties:
|
|
|
|
|
|
|
|
|
|
(:name asciidoc
|
|
|
|
|
:type elpa
|
|
|
|
|
:after (lambda ()
|
|
|
|
|
(autoload 'doc-mode "doc-mode" nil t)
|
|
|
|
|
(add-to-list 'auto-mode-alist '("\\.adoc$" . doc-mode))
|
|
|
|
|
(add-hook 'doc-mode-hook '(lambda ()
|
|
|
|
|
(turn-on-auto-fill)
|
|
|
|
|
(require 'asciidoc)))))
|
|
|
|
|
|
|
|
|
|
(:name anything
|
|
|
|
|
:features anything-config
|
|
|
|
|
:before (global-set-key (kbd "M-s a") 'dim:anything-occur)
|
|
|
|
|
:after (setq w3m-command nil))
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Initialization files, Prev: Before and After properties, Up: User Init
|
|
|
|
|
|
|
|
|
|
7.2 Initialization files
|
|
|
|
|
========================
|
|
|
|
|
|
|
|
|
|
El-Get will see if a file named `init-package.el' exists in the
|
|
|
|
|
directory pointed at by the `el-get-user-package-directory' variable.
|
|
|
|
|
When this variable is not nil and if such a file does exist in the
|
|
|
|
|
directory, then El-Get will load the user init file for PACKAGE.
|
|
|
|
|
|
|
|
|
|
The initialization file is loaded at the same time as the `:after'
|
|
|
|
|
property would have be run, and just before it if you provide both.
|
|
|
|
|
|
|
|
|
|
El-Get automatically byte compiles the init file as needed and load
|
|
|
|
|
the compiled version.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Recipes, Next: Authoring Recipes, Prev: User Init, Up: Top
|
|
|
|
|
|
|
|
|
|
8 Recipes
|
|
|
|
|
*********
|
|
|
|
|
|
|
|
|
|
All of El-Get behavior is controled with recipes that you can share,
|
|
|
|
|
download, update and author. This chapter explain how to manage your
|
|
|
|
|
recipes and how to author them and ship them.
|
|
|
|
|
|
|
|
|
|
Recipes are a list of properties, which are documented in the
|
|
|
|
|
variable EL-GET-SOURCES.
|
|
|
|
|
|
|
|
|
|
* Menu:
|
|
|
|
|
|
|
|
|
|
* Organizing recipes::
|
|
|
|
|
* Getting more recipes::
|
2012-07-31 01:33:55 +08:00
|
|
|
|
* Overriding package files::
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Organizing recipes, Next: Getting more recipes, Up: Recipes
|
|
|
|
|
|
|
|
|
|
8.1 Organizing recipes
|
|
|
|
|
======================
|
|
|
|
|
|
|
|
|
|
El-Get needs to find a package recipe to be able to install or update
|
|
|
|
|
it. After that the recipe content is saved in the status file and
|
|
|
|
|
cached, so that you can still start Emacs even if you remove the recipe
|
|
|
|
|
file.
|
|
|
|
|
|
2013-05-15 20:56:20 +08:00
|
|
|
|
The variable `el-get-recipe-path' is a list of directory paths to
|
|
|
|
|
search for recipe files, in order. The recipe for a package `example'
|
2012-07-18 23:51:15 +08:00
|
|
|
|
must be named `example.rcp'. The first file named that way in the
|
2013-05-15 20:56:20 +08:00
|
|
|
|
`el-get-recipe-path' variable is used as the recipe. If you need to
|
|
|
|
|
change it, you should do so immediately before running `el-get'; see
|
|
|
|
|
the example in *Note Basic Setup::.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
To check which recipe is used for a given package, use either the
|
|
|
|
|
`M-x el-get-describe' or `M-x el-get-find-recipe-file' command.
|
|
|
|
|
|
|
|
|
|
This organisation with several path allow you to setup El-Get to use
|
|
|
|
|
its own recipes, recipes automatically created from online resources
|
|
|
|
|
(such as Emacswiki), and your own local recipes.
|
|
|
|
|
|
|
|
|
|
As it's easy for El-Get to use your own recipes in the exact same way
|
|
|
|
|
than it uses its own recipes, it allows you to share them very easily.
|
|
|
|
|
Send the file to a friend and have it store it at the right place.
|
|
|
|
|
|
|
|
|
|
It's also possible to setup `el-get-sources' with recipe
|
|
|
|
|
information. As long as the `type' property is not filled in
|
|
|
|
|
`el-get-sources', El-Get will first find the recipe as usual and then
|
|
|
|
|
merge the recipe content with the recipe skeleton provided by the
|
|
|
|
|
matching `el-get-sources' stanza.
|
|
|
|
|
|
|
|
|
|
El-Get also supports full User Init files, see *Note User Init::.
|
|
|
|
|
|
|
|
|
|
|
2012-07-31 01:33:55 +08:00
|
|
|
|
File: el-get.info, Node: Getting more recipes, Next: Overriding package files, Prev: Organizing recipes, Up: Recipes
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
8.2 Getting more recipes
|
|
|
|
|
========================
|
|
|
|
|
|
|
|
|
|
The command `M-x el-get-emacswiki-refresh' downloads the list of Emacs
|
|
|
|
|
Lisp files available at EmacsWiki. El-Get is able to automatically
|
|
|
|
|
install any such file at the right place in `el-get-dir'. The
|
|
|
|
|
integration of an automatically generated recipe is often not enough,
|
|
|
|
|
you often have to add some initialisation code. See *Note User Init::.
|
|
|
|
|
|
|
|
|
|
The command `el-get-elpa-build-local-recipes' downloads the list of
|
|
|
|
|
Emacs Lisp Packages from the ELPA archives you have setup, and make
|
|
|
|
|
them automatically available for El-Get.
|
|
|
|
|
|
2012-07-31 01:33:55 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Overriding package files, Prev: Getting more recipes, Up: Recipes
|
|
|
|
|
|
|
|
|
|
8.3 Overriding package files
|
|
|
|
|
============================
|
|
|
|
|
|
|
|
|
|
El-Get manages the files associated with a package. You can browse
|
|
|
|
|
those files using the `el-get-cd' function. It's possible to hack on
|
|
|
|
|
those files, be aware that doing so might break your setup capability
|
|
|
|
|
to handle upgrades.
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Authoring Recipes, Prev: Recipes, Up: Top
|
|
|
|
|
|
|
|
|
|
9 Authoring Recipes
|
|
|
|
|
*******************
|
|
|
|
|
|
|
|
|
|
Authoring recipes is often very easy. El-Get goal is to adapt to any
|
|
|
|
|
Emacs Lisp code and distribution you can find out there in the wild, so
|
|
|
|
|
the list of features supported is quite large. Simple cases are very
|
|
|
|
|
simple, though.
|
|
|
|
|
|
2013-01-05 10:49:05 +08:00
|
|
|
|
If you want to submit recipes as pull request, please make sure to
|
|
|
|
|
run recipe checker (*note Recipe checker::) and paste the result in the
|
|
|
|
|
pull request comment.
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
* Menu:
|
|
|
|
|
|
|
|
|
|
* Recipe format::
|
|
|
|
|
* Dependencies::
|
|
|
|
|
* Byte Compilation::
|
|
|
|
|
* Autoloads::
|
|
|
|
|
* Build::
|
2013-01-05 10:49:05 +08:00
|
|
|
|
* Recipe checker::
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Recipe format, Next: Dependencies, Up: Authoring Recipes
|
|
|
|
|
|
|
|
|
|
9.1 Recipe format
|
|
|
|
|
=================
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
The recipe for the hypothetical package named `el-get-example' must be
|
|
|
|
|
provided in a file named `el-get-example.rcp'. This file will be
|
|
|
|
|
searched for as described in *Note Organizing recipes::. The variable
|
|
|
|
|
`el-get-sources' is also considered as a recipe source, as detailed in
|
|
|
|
|
*Note Organizing recipes::.
|
|
|
|
|
|
|
|
|
|
A recipe file contains a lisp property list. Accepted properties are
|
|
|
|
|
described in the documentation for the variable `el-get-sources', and
|
|
|
|
|
their possible values are described at the same place.
|
|
|
|
|
|
2012-12-15 06:56:54 +08:00
|
|
|
|
If your property list is missing the `:type' property, then it's
|
|
|
|
|
merged with the recipe one, so that you can override any definition
|
|
|
|
|
provided by `el-get' recipes locally.
|
|
|
|
|
|
|
|
|
|
`:name'
|
|
|
|
|
The name of the package. It can be different from the name of the
|
|
|
|
|
directory where the package is stored (after a `git clone' for
|
|
|
|
|
example), in which case a symlink will be created.
|
|
|
|
|
|
|
|
|
|
`:depends'
|
|
|
|
|
A single package name, or a list of package names, on which the
|
|
|
|
|
package depends. All of a packages dependencies will be installed
|
|
|
|
|
before the package is installed.
|
|
|
|
|
|
|
|
|
|
`:builtin'
|
2013-03-02 00:55:29 +08:00
|
|
|
|
A string containing the Emacs version (see EMACS-MAJOR-VERSION
|
|
|
|
|
variable) from which Emacs includes the recipe as a builtin. For
|
|
|
|
|
example, `package.el' (the implementation of ELPA) is part of
|
|
|
|
|
Emacs 24 but needs an external recipe for previous major versions.
|
2012-12-15 06:56:54 +08:00
|
|
|
|
|
2013-05-15 20:56:20 +08:00
|
|
|
|
Unlike the builtin `:type' no `:build' or `:info' properties are
|
|
|
|
|
executed if this matches.
|
|
|
|
|
|
2012-12-15 06:56:54 +08:00
|
|
|
|
`:pkgname'
|
|
|
|
|
The name of the package for the underlying package management
|
|
|
|
|
system (apt-get, fink or pacman, also supported by github and
|
|
|
|
|
emacsmirror), which can be different from the Emacs package name.
|
|
|
|
|
|
|
|
|
|
`:type'
|
|
|
|
|
The type of the package, currently el-get offers support for
|
|
|
|
|
apt-get, elpa, git, github, emacsmirror, git-svn, bzr svn, cvs,
|
|
|
|
|
darcs, fink, ftp, emacswiki, http-tar, pacman, hg and http. You
|
|
|
|
|
can easily support your own types here, see EL-GET-METHODS.
|
|
|
|
|
|
|
|
|
|
`:branch'
|
|
|
|
|
Which branch to fetch when using git (and by extension, github and
|
2014-05-04 03:15:08 +08:00
|
|
|
|
emacsmirror, which are derived from git). Also supported in the
|
2012-12-15 06:56:54 +08:00
|
|
|
|
installer in el-get-install.
|
|
|
|
|
|
|
|
|
|
`:url'
|
|
|
|
|
Where to fetch the package, only meaningful for git and http types.
|
|
|
|
|
|
|
|
|
|
`:username, :pkgname'
|
|
|
|
|
For the github type, these specify the user name and repo name to
|
|
|
|
|
clone from Github. For example, for el-get, the user name would be
|
|
|
|
|
`"dimitri"' , and the repo name would be `"el-get"' . As described
|
|
|
|
|
above, the `:pkgname' property is only required if the repo name
|
|
|
|
|
on Github differs from the Emacs package name. Note that the
|
|
|
|
|
emacsmirror type is just like the github type with `:username' set
|
|
|
|
|
to `"emacsmirror"' .
|
|
|
|
|
|
|
|
|
|
`:build'
|
|
|
|
|
Your build recipe, a list. A build command C whose `car' is a
|
|
|
|
|
symbol (see `symbolp') will be replaced by (eval C).
|
|
|
|
|
|
|
|
|
|
Then, each element of the recipe will be interpreted as a command:
|
|
|
|
|
|
|
|
|
|
If the element is a list of string, the first element of the list
|
|
|
|
|
must be the program to call, and each following element a different
|
|
|
|
|
argument to the call. No whitespace parsing is done.
|
|
|
|
|
|
|
|
|
|
Otherwise, if it is a list, any list sub-elements will be
|
|
|
|
|
recursively "flattened" (see `el-get-flatten'). The resulting
|
|
|
|
|
strings will be interpreted as individual shell arguments,
|
|
|
|
|
appropriately quoted.
|
|
|
|
|
|
|
|
|
|
`:build/system-type'
|
|
|
|
|
Your specific build recipe for a given SYSTEM-TYPE gets there and
|
|
|
|
|
looks like `:build'.
|
|
|
|
|
|
|
|
|
|
`:load-path'
|
|
|
|
|
A directory or a list of directories you want El-Get to add to your
|
|
|
|
|
LOAD-PATH. Those directories are relative to where the package
|
|
|
|
|
gets installed.
|
|
|
|
|
|
|
|
|
|
`:compile'
|
|
|
|
|
Allow to restrict what to byte-compile: by default, El-Get will
|
|
|
|
|
compile all elisp files in the `:load-path' directories, unless a
|
|
|
|
|
`:build' command exists for the package source. Given a `:compile'
|
|
|
|
|
property, El-Get will only byte-compile those given files,
|
|
|
|
|
directories or filename-regexpes in the property value. This
|
|
|
|
|
property can be a `listp' or a `stringp' if you want to compile
|
|
|
|
|
only one of those.
|
|
|
|
|
|
|
|
|
|
`:info'
|
|
|
|
|
This string allows you to setup a directory where to find a
|
|
|
|
|
`package.info' file, or a `path/to/whatever.info' file. It will
|
|
|
|
|
even run `ginstall-info' for you to create the `dir' entry so that
|
|
|
|
|
`C-h i' will be able to list the newly installed documentation.
|
|
|
|
|
Note that you might need to kill (`C-x k' ) your info buffer then
|
|
|
|
|
`C-h i' again to be able to see the new menu entry.
|
|
|
|
|
|
|
|
|
|
`:load'
|
|
|
|
|
List of files to load, or a single file to load after having
|
|
|
|
|
installed the source but before `require'ing its features.
|
|
|
|
|
|
|
|
|
|
`:features'
|
|
|
|
|
List of features el-get will `require' for you.
|
|
|
|
|
|
|
|
|
|
`:autoloads'
|
|
|
|
|
Control whether El-Get should generate autoloads for this package.
|
|
|
|
|
Setting this to `nil' prevents El-Get from generating autoloads
|
|
|
|
|
for the package. Default is `t'. Setting this to a string or a
|
|
|
|
|
list of string will load the named autoload files.
|
|
|
|
|
|
|
|
|
|
`:library'
|
|
|
|
|
When using `:after' but not using `:features' , `:library' allows
|
|
|
|
|
to set the library against which to register the `:after' function
|
|
|
|
|
against `eval-after-load'. It defaults to either `:pkgname' or
|
|
|
|
|
`:package' , in this order. See also `el-get-eval-after-load' .
|
|
|
|
|
|
|
|
|
|
`:options'
|
|
|
|
|
Currently used by http-tar and cvs support. When using http-tar,
|
|
|
|
|
it allows you to give the tar options you want to use. Typically
|
|
|
|
|
would be `"xzf"' , but you might want to choose `"xjf"' for
|
|
|
|
|
handling `.tar.bz' files e.g.
|
|
|
|
|
|
|
|
|
|
When using CVS, when it's set to `"login"', El-Get will first
|
|
|
|
|
issue a `cvs login' against the server, asking you interactively
|
|
|
|
|
(in the minibuffer) any password you might to enter, and only then
|
|
|
|
|
it will run the `cvs checkout' command.
|
|
|
|
|
|
|
|
|
|
`:module'
|
|
|
|
|
Currently only used by the cvs support, allow you to configure the
|
|
|
|
|
module you want to checkout in the given URL.
|
|
|
|
|
|
|
|
|
|
`:repo'
|
|
|
|
|
Only used by the elpa support, a cons cell with the form `(NAME .
|
|
|
|
|
URL)' , as in PACKAGE-ARCHIVES . If the package source only
|
|
|
|
|
specifies a URL, the URL will be used for NAME as well.
|
|
|
|
|
|
|
|
|
|
`:prepare'
|
|
|
|
|
This should be a lisp form to evaluate after both the
|
|
|
|
|
INFO-DIRECTORY-LIST and the LOAD-PATH variables have been taken
|
|
|
|
|
care of, but before loading the package or any further action from
|
|
|
|
|
`el-get-init' . It will be run with DEFAULT-DIRECTORY set to the
|
|
|
|
|
package directory.
|
|
|
|
|
|
|
|
|
|
`:before'
|
|
|
|
|
This exactly like `:prepare' property, but is reserved for user
|
|
|
|
|
customizations in EL-GET-SOURCES . Recipe files should not use
|
|
|
|
|
this property. It will be run just after :prepare.
|
|
|
|
|
|
|
|
|
|
`:post-init'
|
|
|
|
|
This should be a lisp form to evaluate after loading the package.
|
|
|
|
|
Intended for use from recipes. This function is registered for
|
|
|
|
|
`eval-after-load' against the recipe library by `el-get-init' once
|
|
|
|
|
the `:load' and `:features' have been setup. Like `:prepare' , it
|
|
|
|
|
will be run with DEFAULT-DIRECTORY set to the package directory.
|
|
|
|
|
|
|
|
|
|
`:after'
|
|
|
|
|
This exactly like the `:post-init' property, but is reserved for
|
|
|
|
|
user customizations in EL-GET-SOURCES. Recipe files should not
|
|
|
|
|
use this property. It will be run just after `:post-init' and
|
|
|
|
|
after any per-package user-init-file (see
|
|
|
|
|
EL-GET-USER-PACKAGE-DIRECTORY).
|
|
|
|
|
|
|
|
|
|
`:lazy'
|
|
|
|
|
Default to `nil' . Allows to override EL-GET-IS-LAZY per package.
|
|
|
|
|
|
|
|
|
|
`:localname'
|
|
|
|
|
Currently only used by both `http' and `ftp' supports, allows to
|
|
|
|
|
specify the target name of the downloaded file.
|
|
|
|
|
|
|
|
|
|
This option is useful if the package should be retrieved using a
|
|
|
|
|
presentation interface (such as as web SCM tool).
|
|
|
|
|
|
|
|
|
|
For example, destination should be set to `package.el' if the
|
|
|
|
|
package url has the following scheme:
|
|
|
|
|
|
|
|
|
|
"http://www.example.com/show-as-text?file=path/package.el"
|
|
|
|
|
|
|
|
|
|
`:website'
|
|
|
|
|
The website of the project.
|
|
|
|
|
|
|
|
|
|
`:description'
|
|
|
|
|
A short description of the project.
|
|
|
|
|
|
|
|
|
|
`:checksum'
|
|
|
|
|
Some methods in El-Get download files that are not so trusted
|
|
|
|
|
(e.g. anyone is allowed to modify emacswiki anytime). For these
|
|
|
|
|
cases you can set up a checksum value for a package, so you will
|
|
|
|
|
notice if El-Get tries to install a version that you haven't seen
|
|
|
|
|
before. The installation will simply fail and you will see the
|
|
|
|
|
good and bad checksum values in `*Messages*'. To get the checksum
|
|
|
|
|
value for a package initially, install the package while
|
|
|
|
|
EL-GET-VERBOSE is on.
|
|
|
|
|
|
|
|
|
|
Checksum calculation is currently supported by these methods with
|
|
|
|
|
the following meaning:
|
|
|
|
|
|
|
|
|
|
http, ftp and emacswiki with the SHA1 of the downloaded file
|
|
|
|
|
|
|
|
|
|
git in which it is an alias for `:checkout' (see below)
|
|
|
|
|
|
|
|
|
|
`:checkout'
|
|
|
|
|
A git refspec (branch, tag, commit hash) that should be checked out
|
|
|
|
|
after cloning the git repository. If provided, this overrides any
|
|
|
|
|
value for the `:branch' property. Unlike the `:branch' property,
|
|
|
|
|
this can be any valid argument to git checkout, including a tag
|
|
|
|
|
name or a commit hash. The intended use of this property is to
|
|
|
|
|
"lock" a repository at a particular revision, regardless of what
|
|
|
|
|
happens to the repo upstream.
|
|
|
|
|
|
|
|
|
|
Currently this property only has meaning for git type recipes.
|
|
|
|
|
Other VCS-based methods may implement support in the future.
|
|
|
|
|
|
|
|
|
|
`:shallow'
|
|
|
|
|
If set to t in a git recipe, `git-clone' will be run with `--depth
|
|
|
|
|
1' , which will create a so-called shallow clone by not
|
|
|
|
|
downloading all the history of the repository. The default is
|
|
|
|
|
controlled by the variable EL-GET-GIT-SHALLOW-CLONE, which is
|
|
|
|
|
`nil' by default.
|
|
|
|
|
|
|
|
|
|
`:submodule'
|
|
|
|
|
If set to `nil' in a git recipe, submodules will not be updated.
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
File: el-get.info, Node: Dependencies, Next: Byte Compilation, Prev: Recipe format, Up: Authoring Recipes
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
9.2 Dependencies
|
|
|
|
|
================
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
When a recipe provides a `:depends' property, El-Get makes sure that
|
|
|
|
|
the given list of packages is installed and initialized before the
|
|
|
|
|
package for the current recipe is installed and initialized.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
File: el-get.info, Node: Byte Compilation, Next: Autoloads, Prev: Dependencies, Up: Authoring Recipes
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
9.3 Byte Compilation
|
2012-07-18 23:51:15 +08:00
|
|
|
|
====================
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
By default, El-Get will recursively byte-compile the directory where
|
|
|
|
|
the package is installed, that is each and any file called
|
|
|
|
|
`something.el'. Some packages include non Emacs Lisp directories, and
|
|
|
|
|
sometime test files that are not meant to pass byte compilation without
|
|
|
|
|
errors or warnings. It is possible to setup your recipe to either only
|
|
|
|
|
target some files of the package, or to bypass byte compiling entirely.
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Autoloads, Next: Build, Prev: Byte Compilation, Up: Authoring Recipes
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
9.4 Autoloads
|
2012-07-18 23:51:15 +08:00
|
|
|
|
=============
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
Think about providing `autoloads' for your recipe if some are
|
|
|
|
|
available. You can provide them yourself too, for packages that should
|
|
|
|
|
have support for autoloads but ship without them.
|
|
|
|
|
|
|
|
|
|
The `:prepare' property of a recipe is the right place where to put
|
|
|
|
|
added autoloads, as shown in this example:
|
|
|
|
|
|
|
|
|
|
(:name undo-tree
|
|
|
|
|
:description "Treat undo history as a tree"
|
|
|
|
|
:type git
|
|
|
|
|
:url "http://www.dr-qubit.org/git/undo-tree.git"
|
|
|
|
|
:prepare (progn
|
|
|
|
|
(autoload 'undo-tree-mode "undo-tree.el"
|
|
|
|
|
"Undo tree mode; see undo-tree.el for details" t)
|
|
|
|
|
(autoload 'global-undo-tree-mode "undo-tree.el"
|
|
|
|
|
"Global undo tree mode" t)))
|
|
|
|
|
|
|
|
|
|
The `:prepare' property of a recipe is considered the same as the
|
|
|
|
|
`:before' one, just evaluated after it. `:prepare' is meant for recipe
|
|
|
|
|
authors whereas `:before' is meant for user customisations. See *Note
|
|
|
|
|
Before and After properties::.
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2013-01-05 10:49:05 +08:00
|
|
|
|
File: el-get.info, Node: Build, Next: Recipe checker, Prev: Autoloads, Up: Authoring Recipes
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
9.5 Build
|
2012-07-18 23:51:15 +08:00
|
|
|
|
=========
|
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
The `:build' property of the recipe allows for OS integration at build
|
|
|
|
|
time. Build happens after the package has been fetched, and allows to
|
|
|
|
|
run commands such as `make'.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
The variable `el-get-emacs' contains the complete path where to find
|
|
|
|
|
the current Emacs executable you're running, as that's something build
|
|
|
|
|
commands often need.
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
As shell interpolation can get hairy, El-Get offers you to setup your
|
|
|
|
|
build commands as Emacs Lisp list. See the magit recipe for an example:
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2012-07-24 02:51:01 +08:00
|
|
|
|
(:name magit
|
|
|
|
|
:website "https://github.com/magit/magit#readme"
|
|
|
|
|
:description "It's Magit! An Emacs mode for Git."
|
|
|
|
|
:type github
|
|
|
|
|
:pkgname "magit/magit"
|
|
|
|
|
:info "."
|
|
|
|
|
:autoloads ("50magit")
|
|
|
|
|
:build (("make" "all"))
|
|
|
|
|
:build/darwin `(,(concat "make EMACS=" el-get-emacs " all")))
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
2013-01-05 10:49:05 +08:00
|
|
|
|
|
|
|
|
|
File: el-get.info, Node: Recipe checker, Prev: Build, Up: Authoring Recipes
|
|
|
|
|
|
|
|
|
|
9.6 Recipe checker
|
|
|
|
|
==================
|
|
|
|
|
|
|
|
|
|
There are two ways to run recipe checker. One is to run it as an Emacs
|
|
|
|
|
command. Run `el-get-check-recipe' in the buffer opening the recipe to
|
|
|
|
|
be checked. You can also use a script to run the checker. This is
|
|
|
|
|
convenient if you want to check multiple recipes at once.
|
|
|
|
|
|
|
|
|
|
test/check-recipe.el PATH/TO/RECIPE.rcp ANOTHER/RECIPE.rcp ...
|
|
|
|
|
|
|
|
|
|
MS Windows user may need to call the script like this:
|
|
|
|
|
|
|
|
|
|
emacs -batch -Q -l test/check-recipe.el PATH/TO/RECIPE.rcp ...
|
|
|
|
|
|
2014-01-20 23:56:09 +08:00
|
|
|
|
You can also test the recipe with `test/test-recipe.sh'. This will
|
|
|
|
|
actually install the package in a test environment. An interactive
|
|
|
|
|
version `test/test-recipe-interactive.sh' is also available.
|
|
|
|
|
|
|
|
|
|
test/test-recipe.sh PATH/TO/RECIPE.rcp
|
|
|
|
|
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Tag Table:
|
2014-05-04 03:15:08 +08:00
|
|
|
|
Node: Top769
|
|
|
|
|
Node: Introduction1234
|
|
|
|
|
Node: Acknowledgments2534
|
|
|
|
|
Node: Glossary4116
|
|
|
|
|
Ref: Glossary - Init5212
|
|
|
|
|
Ref: Glossary - Install5514
|
|
|
|
|
Ref: Glossary - Recipe6607
|
|
|
|
|
Ref: Glossary - Status7031
|
|
|
|
|
Ref: Glossary - Update7289
|
|
|
|
|
Node: Installing7527
|
2018-01-24 10:55:05 +08:00
|
|
|
|
Node: Install the developer version8433
|
|
|
|
|
Node: Skip Emacswiki recipes when installing9174
|
|
|
|
|
Node: Shallow clone when installing10047
|
|
|
|
|
Node: Usage10603
|
|
|
|
|
Node: Setup12892
|
|
|
|
|
Node: Basic Setup13316
|
|
|
|
|
Node: The el-get function14627
|
|
|
|
|
Node: Distributed Setup15903
|
|
|
|
|
Node: The el-get-bundle macro18813
|
|
|
|
|
Node: Setup Customization24759
|
|
|
|
|
Node: User Init26177
|
|
|
|
|
Node: Before and After properties26864
|
|
|
|
|
Node: Initialization files28372
|
|
|
|
|
Node: Recipes29025
|
|
|
|
|
Node: Organizing recipes29500
|
|
|
|
|
Node: Getting more recipes31131
|
|
|
|
|
Node: Overriding package files31829
|
|
|
|
|
Node: Authoring Recipes32212
|
|
|
|
|
Node: Recipe format32827
|
|
|
|
|
Node: Dependencies42616
|
|
|
|
|
Node: Byte Compilation42962
|
|
|
|
|
Node: Autoloads43528
|
|
|
|
|
Node: Build44654
|
|
|
|
|
Node: Recipe checker45626
|
2012-07-18 23:51:15 +08:00
|
|
|
|
|
|
|
|
|
End Tag Table
|