Moving to Spacemacs
I recently declared, if not quite .emacs bankruptcy , then at least Chapter 11 status. After a long time keeping my .emacs as a single file, I refactored it into a set of self contained lisp files of the form:
(require 'other-peoples-packages) ...my config... (provide 'my-package)
Then I just ensured the director with all these files was on my
load-path and simply
required my own little packages.
This worked very nicely, and seemed to have the side effect of speeding up Emacs startup. However, I still had quite a way to go to configure a proper development environment, especially code completion, so I decided to take a look at Spacemacs since it claims to have such stuff “preconfigured, out of the box”. Interestingly, it seemed to be using many of the packages that I was already using in my own configuration, so I hoped to be able to eliminate some of my own code.
To avoid clobbering my existing Emacs configuration I created a new user in Linux Mint and simply followed the instructions at the Github repo. The first time that Spacemacs starts you are asked what editing style you prefer - Vim or Emacs - and it downloads a lot of packages from the Emacs package archives.
I had previously been put off from Spacemacs by the stress that the documentation places on Evil mode, however I am pleased to report that if you choose Emacs style editing then, as far as I can tell, it works just like standard Emacs does - at least if you are used to Helm and Hydra.
Porting my .emacs configuration
Once I was up and running the process of porting my existing .emacs began. This was a frustrating process to begin with, it took me a few days to grok what was really happening. It has to be said that the documentation is excellent, but there is a lot to take in at one sitting.
As an experienced Emacs user with a significant amount of configuration to
port, the advice
to put most of your customization in the
doesn’t feel like a good move. It could end up being huge and would in fact be a
backward step from my nicely modularized configuration.
The route I quickly decided on was to write my own Spacemacs layer, which I called simply “pd”. Layers come with a pre-defined set of files which are loaded in a specific order:
- layers.el (declare “extra” layers)
- packages.el (where you configure the packages you are using)
- funcs.el (where you declare functions, obviously)
- config.el (for your layer’s variables)
- keybindings.el (general keybindings, not package specific)
keybindings.el were pretty easy to port. Writing
was a bit more challenging, one issue that I ran into was that I wanted to use a
function that I had declared in
funcs.el as part of my initialization but it
wasn’t loaded by then. It would make more sense to me to load
packages.el, but when you start to use a framework like Spacemacs you have to
work within the constraints it sets you. My
packages.el has actually ended up
pretty small, it just brings in a few little custom packages that I like to use.
Incidentally, the trick to reusing packages that are not on ELPA - whether they
are yours or anyone else’s - is just to create a folder under your layer called
“local”, for example, under my “pd” layer I have the
download from the Emacs wiki, and a package of my own containing hydras:
I can then initialize them simply within
(defun pd/init-pd-hydra () (use-package pd-hydra))
I still have quite a number of settings that are not related to any package in
particular, and these have all ended up in the
function. However, since Spacemacs seems so well configured out of the box, it’s
a much smaller list than I used to have in my own .emacs configuration.
Spacemacs uses Hydra to create what it calls
“Transient States”. One that caught my attention was the “Window Manipulation
Transient State”. which is bound to
SPC w . by default. I had previously
developed my own very similar hydra, though with non-VIM keybindings and some
extra functions, such as the ability to open
helm-mini, bring up dired, save
the current buffer etc.
I couldn’t figure out a way of augmenting a built-in hydra - not really
surprising because the design of them is so intricate, especially if they use a
docstring. So I just copied the built-in one, pasted it into my
and hacked it until I had it just how I wanted it. Then I bound it to the
(spacemacs|define-transient-state pd-window-manipulation :title "Phil's Window Manipulation Transient State." :doc (concat "M-arrow = select, M-S-arrow = move, S-arrow = resize. 0-9 = select window N. Split^^ Buffers^^ Windows^^ Files^^ Other ─────^^───────────── ───────^^───── ───────^^───────── ─────^^──────── ─────^^────────────────── [___] vertical [_n_] next [_c_] close [_b_] helm mini [_u_] restore prev layout [_V_] vert & follow [_p_] previous [_o_] close others [_f_] helm find [_U_] restore next layout [_|_] horizontal [_k_] kill [_r_] rotate fwd [_d_] dired [_F_] go to other frame [_H_] horiz & follow [_s_] save [_R_] rotate bwd [_t_] terminal [_g_] golden-ratio-mode") ... (spacemacs/set-leader-keys "w." 'spacemacs/pd-window-manipulation-transient-state/body)
The full thing can be found here, but be warned, it is still evolving!
One of the first things I wanted to change in Spacemacs was the default theme. Just my luck that my longstanding favourite theme Sellout’s Solarized uses a non-standard loading mechanism and was a bit tricky to configure. I have another post detailing how to do it.
After hacking on it on and off for about a week I now have a Spacemacs
configuration that contains everything I deemed really important from my own
config, and in fact the amount of configuration code I need seems to have
diminished quite significantly. I was really surprised how small my
packages.el file had become when I reviewed it for this post.
Sometime in the not too distant future I expect to be moving over to using Spacemacs rather than my old config. Just need to perfect my hyper key on Linux first…I also want to take the opportunity to produce a set of keybindings that are much more in line with the Windows and Visual Studio defaults.
If you are a new Emacs user or don’t have much invested in your
would say it is a no-brainer - you should definitely start with Spacemacs rather
than Emacs. It is just a much better out-of-the-box experience.
If you are an intermediate or advanced user with a lot of configuration investment, then I would still consider the switch worthwhile, but it will probably take a little longer to get back to status quo. It would be nice if the Spacemacs documentation had more guidance for users in this situation.