(Edit: I've wrapped this approach up into a shell script which I've added to the EmacsWiki.)
I'd be inclined to use the $HOME
environment variable:
Firstly copy the 'distribution' (for want of a better term) into a sub-directory .emacs.d
of a directory which will serve as the replacement $HOME
for that distribution. i.e. /path/to/(distribution)/.emacs.d
:
$ git clone https://github.com/bbatsov/prelude.git ~/emacs/prelude/.emacs.d
$ git clone https://github.com/overtone/emacs-live.git ~/emacs/emacs-live/.emacs.d
Then you can start emacs using env
to set the HOME
environment variable locally for that command:
$ env HOME=$HOME/emacs/prelude emacs
$ env HOME=$HOME/emacs/emacs-live emacs
They shouldn't interact with each other, so you can run them together and have multiple side-by-side emacs instances, each using a different configuration.
I see that graphene is actually an ELPA package, so it has no init.el
file and needs to be installed via the package manager; but you can still use the same technique to install it in a separate clean configuration: Simply make a similar directory structure to the others, then create an init.el file (e.g. ~/emacs/graphene/.emacs.d/init.el
) containing the code from the graphene installation instructions, then run emacs (e.g. env HOME=$HOME/emacs/graphene emacs
), and finish the remainder of the installation instructions.
The down-side to this technique is that Emacs won't see all your other dot files (because it will be looking in $HOME
), and so running other processes from within Emacs won't necessarily work as normal; but that's not likely to be a huge issue if you're just experimenting, and you can always symlink or copy the bits you need.
You may even prefer it that way -- the benefit is that if anything in the distribution you're trialing writes files to the home directory, it's not going to clobber your real files.
This may also be a useful approach when upgrading Emacs to a new release (if you can run both the old and the new versions side by side) as you could set up a copy of your existing config to use with the new Emacs until you're convinced everything is working, and you can edit the new config without the risk of breaking your existing one. Or flip that around, and instead keep the original config in the new/alternate location, in case you need it as a back-up.
(require 'prelude...
in your initialization file -- e.g.,.emacs
orinit.el
. – Knighthood