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.