Emacs

Modernizing my Emacs Configuration

I’ve been using Emacs for well over a decade at this point. Over the years my configuration for Emacs has grown and evolved. I’ve always appreciated the ability to change basically any aspect with some Lisp, and I am an inveterate tinkerer.

The end result of 10+ years of tinkering was an Emacs config that, while functional and tuned to my needs, was hard to understand and change. While I have changed it continuously over the years, I had not revisited the basic structure of my configs since Emacs 24 shipped ELPA in 2012. As such I decided to undertake the effort to modernize and reorganize things.

Previous Setup

My Emacs configs were previously split up across several files:

  • ~/.emacs: The core init file. Here I would enable various packages and set configuration variables.
  • ~/.emacs.d/elisp/keyboard-shortcuts.el: Here I would define any custom keybindings, both global and for specific modes.
  • ~/.emacs.d/elisp/mode-hooks.el: Here I would define custom hooks to change the behavior of various modes. Any add-hook call using built-in hooks went here too.
  • ~/.emacs.d/elisp/functions.el: Here I defined any custom functions other than mode hooks.

This setup was basically unchanged since I first split up my original .emacs file (probably circa 2010 though I don’t have the git history from that time). This did have the advantage of mostly making sense to me for code organization. If I wanted to add something new or find an existing setting, it was easy for me to know where I would have put it. The downsides were basically everything else.

In particular I had the following problems:

  1. No real structure. While finding the right file was easy, within that file there was no real organization. While I tried to group related things together, this did not work out in practice. Finding a particular setting was a matter of searching. In a couple cases I had redundant settings because I missed that I had configured something previously.
  2. Configuration sprawl. The settings for a particular package were not always in one place. Complex packages, like Helm, had configuration spread across all the files listed above. This made it hard to understand how I had configured each package.
  3. No documentation. My Emacs configs had been built up organically over years, and I was not always good at documenting why I did things. I had started keeping the configs in git around 2009, but for various reasons I won’t go into here my current history only goes back to 2014. Consequently I had many settings where it was unclear whether or not it was still useful or important to me. This was exacerbated by configs accumulated from past jobs that were no longer relevant.
  4. Not up to modern standards. The Emacs community continues to evolve the best practices for configuration. I was more active in the community during undergrad, but had fallen away from it since. As such I was still using patterns from almost a decade ago. In particular I wanted to address using ~/.emacs.d/init.el in favor of ~/.emacs and using use-package for package management.

Reorganization and Cleanup

The first step I undertook was to clean up and reorganize my configs. First off I did two basic things:

  1. Move my ~/.emacs to ~/.emacs.d/init.el. This was nothing more than moving the file.
  2. Remove unused settings. I had accumulated configuration for various programming languages from past jobs and projects. If I wasn’t actively using it, I decided to rip it out. I’d likely want something new anyway if I did come back to it. I know I didn’t get everything unused here, but I wanted to at least remove the biggest offenders.

This got my configs to a slightly cleaner place. The next step was to reorganize into new modules. My goal was to pull as much as possible out of init.el and put everything into a small number of new modules. I settled on the following structure:

  1. appearance.el: All configuration related to changing the Emacs UI
  2. base.el: Core Emacs configuration independent of any particular mode or workflow
  3. editor.el: Core text/code editing configuration
  4. modes.el: Specific configuration for various modes
  5. work.el: Any configuration specific to my work setup that I didn’t use for personal projects.

I started out just reorganizing things. Once I got everything into the new locations, I took another pass to clean up unused settings, since the new layout gave me a fresh view of things.

The next step was to start using use-package. This is a very nice library that solves several problems with Emacs package configuration:

  • Automatically installs missing packages
  • Standard layout and location for package configuration
  • Defer loading certain packages for faster startup

This was a somewhat tedious process of going through each (require 'package) in my configuration and converting it to use-package by moving all the related configuration into use-package’s structure. Once I had done that I took a pass through my list of installed packages in package-selected-packages to confirm they were all explicitly loaded, and removed everything unused. Altogether I think I removed ~20% of the packages I had installed previously and got my Emacs startup time down to ~1.5 seconds. I don’t usually care about this much since I only start Emacs once a day, but this was a big improvements from the 5-10 second range it was in previously.

You can see what all of these changes looked like if you compare afcc501c15d05200e39b5e833854d9f12b3c7c1a to 3c43236132c45b1d022bc4917dccf25ad0b743c7.

Originally I was going to stop with this new organization. However, I felt it hadn’t totally addressed the documentation problem, so I decided to keep tinkering.

Org-Babel

As I had been researching the changes I wanted to make to my configs, I came across many people online who used org-babel to structure their Emacs configuration. I was attracted to this because org-mode provides good structure, is well-integrated with Github, and allowed for more detailed documentation.

This did mean I needed to redo the structure of my configs yet again, but since I had cleaned things up in the previous move, it was much easier this time around. To begin, ~/.emacs.d/README.org is now my core init file. ~/.emacs.d/init.el becomes just a single line:

(org-babel-load-file (expand-file-name "README.org" user-emacs-directory))

Almost all other configuration goes into README.org, with two exceptions:

  1. ~/.emacs.d/early-init.el contains some settings that need to happen at the very start of loading (mostly GC/performance related).
  2. ~/.emacs.d/custom.el is managed by the built-in Custom system. I don’t use this directly, but the package manager does. I don’t want these messing up my core configs and there is nothing I care about in them, so they can go in a separate file.

org-babel allows mixing org-mode markup and code. I used org-mode’s standard headings and list to structure and organize the file. My actual config goes into code blocks. A simple example of this looks like so:

Next I disable the toolbar, scrollbar, and menu as I find them unncessary:
#+BEGIN_SRC emacs-lisp
(tool-bar-mode -1)
(scroll-bar-mode -1)
(menu-bar-mode nil)
#+END_SRC

Everything between the BEGIN_SRC/END_SRC lines is actual Emacs Lisp code that makes up my configuration.

Results

All in all I’m happy with the results. You can see the final project at https://github.com/ajsquared/home-osx/tree/master/.emacs.d. There’s more I could do here, like linking to package documentation or adding more detailed reasoning for each setting, but I don’t think this is particularly pressing. I now have a much more well-structured and explainable configuration, and think it is also much more easily shared.

I’d definitely recommend the org-babel approach and use-package to anyone who uses Emacs.

Suppressing ad-handle-definition Warnings in Emacs

As I have been tweaking my Emacs configuration, I noticed that I was getting warnings like the following in *Messages* during Emacs startup:

ad-handle-definition: `tramp-read-passwd' got redefined

I looked into it and these warnings are generated when functions are redefined with defadvice. Most of the warnings I received were coming from third-party packages I had installed, not my own configuration. In any case, they were not helpful, just noise during Emacs startup.

Like everything in Emacs, this is configurable. Turning off the warnings is as easy as adding:

(setq ad-redefinition-action 'accept)

To your .emacs file. I found I had to add it fairly early to ensure that all the warnings were removed.

New Year, New Tools

New Year, New Tools

It’s a new year, so I thought it would be a good time to review some new tools I started using over the last year.

Mosh

Mosh is a replacement for SSH that handles intermittent connectivity. It will warn you if your connection drops and automatically reconnect. This handles situations like putting your laptop to sleep or changing between different connections (e.g. switching from Ethernet to Wifi). I’m connected to a bunch of different servers over the course of the day, so being able to put my laptop to sleep and have it wake back up with my remote sessions intact is incredibly useful. It’s hard to believe I used to work without it.

Mosh doesn’t support X11 forwarding or non-interactive uses of SSH, like port forwarding. However, I don’t use these particularly often, so in practice I’m not bothered by this. In any case, regular SSH is still available!

zsh

I had resisted changing shells for a long time. Bash is available pretty much everywhere. I had a nice .bashrc that I could put anywhere and have the environment I was used it. zsh had been recommended to me several times, but I was concerned about the effort needed to get up and running on a new machine. I liked being able to just drop a few dotfiles in my home directory – would I also have to install zsh?

I decided to try the switch after getting fed up with an issue with my bash prompt and long lines – characters would occasionally get doubled. I am really glad I made the switch. Needing to install zsh wasn’t as big of a deal as I had feared. I used oh-my-zsh to get started. This gave me a lot of the configuration I had done manually in my .bashrc out of the box. Plus it provides plugins for just about anything you might use in the shell. My favorite feature of zsh itself is the improved tab completion. It’s hard to explain without experiencing it – just give zsh a try.

tmux

Much like bash, I had used screen for a while and it just worked. I had a configuration I liked and I didn’t need to think about it. When I was switching to zsh, I decided to reevaluate screen as well and give tmux a try. There aren’t a lot of major differences here, but I’m sticking with tmux. The documentation is better, window splitting feels nicer, and the memory usage is lower. The biggest gain from switching is the configuration format. I find tmux’s configuration file much easier to understand and modify. Just compare the status line from my .screenrc to the same status line from my .tmux.conf.

Helm

The scope of customization for Emacs is astoundingly broad. It’s one of my favorite parts of using Emacs – anything I want to do can be made better with the judicious application of some Lisp. The downfall of this is that it can be hard to keep up with all the options. When I first starting using Emacs in 2008, I was looking for a library for completing file names. I tried out two candidates: ido-mode and anything.el. ido was easy to set up and use, so I went with it. I kept using ido because it worked great. I hadn’t even considered switching until I came across this article on Helm. Helm is a fork of anything.el that cleans up the code and makes it more modular.

I read through that article and was immediately sold on using Helm. Switching to Helm has been the best change to my text editing workflow since switching to Emacs! It provides a consistent interface for completing anything. The fuzzy matching is far ahead of anything else I’ve used. Despite this power, it’s still incredibly fast. Even with very large lists of completion candidates there is no noticeable slowdown.

I encourage you to try out Helm rather than just reading about it. It is a bit different than other completion libraries for Emacs, and it did take me a couple of days to really get used to it. It was time well-spent, however.

Configuring Emacs for Go Development

Setting Up Emacs for Go Development

I’ve recently started learning Go, and, as with any language, I want to configure Emacs as much as possible for Go development. After scouring the Internet, this is what I’ve come up with.

Prerequisites

You’ll need Emacs and Go installed. I’m using OS X, so I use Emacs from http://emacsformacosx.com/ and this Go package.

Once you’ve installed everything, you’ll need to set a few environment variables:

export GOROOT=/usr/local/go
export GOPATH=$HOME/Documents/projects/go
export PATH=$PATH:$GOROOT/bin

You can set $GOPATH to a different directory if you like.

go-mode

The first thing you’ll need for Go development in Emacs is go-mode. You can install this easily in Emacs 24 and up with M-x package-install go-mode.

Installing go-mode will also let you pull up documention on the standard library or third-party packages with M-x godoc. To make godoc work correctly, you’ll need to make sure Emacs has the correct values of $PATH and $GOPATH. This shouldn’t be an issue unless you’re using GUI Emacs on OS X. If you are, I’d recommend using my env-var-import package to import their values from the shell. That package will also set exec-path correctly from your $PATH, which will be important in later steps.

go-eldoc

If you’ve done any Elisp development, you’re probably familiar with eldoc. If not, eldoc shows you the argument list of the function at your point in the minibuffer. go-eldoc is a package that does this for Go. You can install it with M-x package-install go-eldoc. Once you’ve done that, you’ll need to enable it:

(defun go-mode-setup ()
  (go-eldoc-setup))

(add-hook 'go-mode-hook 'go-mode-setup)

gofmt

One of the things I really like about go is the automatic enforcement of a consistent coding style via gofmt. You could manually run this on your code, but go-mode lets you configure Emacs to run it automatically when you save a buffer:

(defun go-mode-setup ()
 (go-eldoc-setup)
 (add-hook 'before-save-hook 'gofmt-before-save))
(add-hook 'go-mode-hook 'go-mode-setup)

goimports

There is also a tool called goimports that not only formats your code like gofmt but also automatically updates all your imports. I’d recommend using this instead of gofmt.

You’ll need Mercurial installed first in order to install it. Then you can run go get code.google.com/p/go.tools/cmd/goimports. Now you can tell Emacs to use goimports instead of gofmt:

(defun go-mode-setup ()
 (go-eldoc-setup)
 (setq gofmt-command "goimports")
 (add-hook 'before-save-hook 'gofmt-before-save))
(add-hook 'go-mode-hook 'go-mode-setup)

godef

Installing go-mode will also give you godef, which will let you jump to the definition of a function like in an IDE. You can jump with M-x godef-jump and then return to the original point with M-*. I bound godef-jump to M-. for ease of use:

(defun go-mode-setup ()
 (go-eldoc-setup)
 (setq gofmt-command "goimports")
 (add-hook 'before-save-hook 'gofmt-before-save)
 (local-set-key (kbd "M-.") 'godef-jump))
(add-hook 'go-mode-hook 'go-mode-setup)

Custom compile command

You can use M-x compile to compile and test your code from Emacs. You’ll just need to set the command that compile runs:

(defun go-mode-setup ()
 (setq compile-command "go build -v && go test -v && go vet")
 (define-key (current-local-map) "\C-c\C-c" 'compile)
 (go-eldoc-setup)
 (setq gofmt-command "goimports")
 (add-hook 'before-save-hook 'gofmt-before-save)
 (local-set-key (kbd "M-.") 'godef-jump))
(add-hook 'go-mode-hook 'go-mode-setup)

I also bound C-c C-c to run compile.

Autocomplete

The last step is to set up autocompletion for Go. I use the auto-complete package for other languages, so it’s natural to use it here too. For Go-aware autocomplete, you’ll need to install the gocode tool first with go get -u -v github.com/nsf/gocode. Then you can install auto-complete with M-x package-install auto-complete and go-autocomplete with M-x package-install go-autocomplete. Once you’ve installed everything add the following to your Emacs configuration:

(require 'auto-complete-config)
(require 'go-autocomplete)

Now you’re ready to start writing some Go in Emacs!

env-var-import

env-var-import

Writing my last post on setting environment variables in GUI Emacs got me thinking about a more general solution to that problem. Rather than requiring everyone to define a function like set-exec-path-from-shell-PATH, it would be nice if there were a package that would handle importing everything for you given a list of environment variables.

To that end I wrote env-var-import. It’s available in Marmalade for easy installation: package-install env-var-import.

Once you’ve installed it, add (require 'env-var-import) to your Emacs configuration and you’re ready to do some importing!

You have two options for using it:

  1. (env-var-import): In this mode, it will only import the environment variable defined by env-var-import-exec-path-var and set exec-path to the value of that variable. env-var-import-exec-path-var defaults to to PATH but can be customized.
  2. (env-var-import '("VAR1" "VAR2")): In this mode it will still import the value of the environment variable defined in env-var-import-exec-path-var and set exec-path to that value. However, it will also import the values of VAR1 and VAR2.

Setting Environment Variables in GUI Emacs

I use Emacs for most of my development work. When I’m not SSHed into a remote machine I generally stick with the GUI Emacs. On OS X this has the downside of not inheriting environment variables from your shell.

I could work around this by using setenv, but that would require me to duplicate the values of those variables. Thankfully there is a better solution:

(defun set-exec-path-from-shell-PATH ()
  (let ((path-from-shell (shell-command-to-string "$SHELL -i -c 'echo $PATH'")))
    (setenv "PATH" path-from-shell)
    (setq exec-path (split-string path-from-shell path-separator))))

This will invoke the shell to get the value of $PATH and then use setenv to set it. Then all you need to do is add (if window-system (set-exec-path-from-shell-PATH)) to your Emacs configuration.

There is nothing special about $PATH in this regard. You could easily extend this function to set other environment variables as needed.

I originally found this code on the Clojure mailing list.