Another Take on Emacs Configuration

I've mentioned before that Emacs configuration is a black hole that can easily swallow any spare cycles that wander into its event horizon. Part of that for me is reading how other people do it. Over at MetaSandwich, Selah has an interesting take on how to do it correctly. One of the things that makes it interesting for me is that he is one of the few people I've read who do essentially what I do.

He writes about what he considers the two main problems in Emacs configuration:

  1. How you should arrange the configuration file to make Emacs startup as fast as possible.
  2. Where should you put things.

Selah says he used to spend a lot of time worrying about how to minimize his startup time. Then one day he realized that, hey, it doesn't really matter. It doesn't matter because he, like most of us, doesn't restart Emacs very often. He starts his once or twice a week; I keep mine going for weeks at a time. I usually start Emacs only at boot time and I reboot only for an OS upgrade or, in the case of my laptop, if I'm traveling. So startup time doesn't matter very much. As Selah points out, even if it took 30 seconds that's less than a minute a week (for him) and maybe 5 seconds for me.

As it turns out, emacs-init-time tells me that my current startup time on my iMac is 4.8 seconds without me spending a single second trying to optimize it. Why should I worry about it? I feel confident that that's true for most of us.

The second problem is a little more controversial. Most of the Emacs hackers that I respect tend to have a complicated configuration architecture with several files and even subdirectories. Look at Steve Purcell's or Magnar Sveen's configurations for examples of that strategy. I on the other hand keep pretty much everything in init.el. Recently, I boldly struck out for uncharted territory and moved machine and platform specific configurations into their own small files that get loaded automatically based on the system-name and system-type variables but mostly everything lives in a single file.

I've often felt like the Maytag repairman because of my preference for a single file but now Selah joins the party and makes a pretty good case for having a single file. He even gives a little code that arranges a handy index of your init.el for use with imenu. That's nice but I don't need even that. I pretty much know where things are in my init.el and I have headers for the various sections so I can go right to them with incremental search.

In the end, of course, there's no right or wrong way, just personal preferences. Still, I seem to be endlessly fascinated by how people do their configurations (and what's in them, of course) so if you want to share your methods, leave a comment.

This entry was posted in General and tagged . Bookmark the permalink.
  • Anders Waldenborg

    I'm happy with my org based setup. My init.el is tangled from a single org file. It can be found here: with links to both tangled and html version.

  • Phil

    I have a fairly large number of files in my config. I find it convenient to type things like C-h C-l my-k TAB RET if I want to edit my-keybindings.el (nothing else starts with "my-k", so TAB completion, and I have C-h C-l bound to find-library

    I can load up any of my config files quickly in that fashion, and no file is overwhelmingly large.

    If I was to put everything in init.el, I suspect I'd at least make heavy use of page breaks so that I could use C-x n p to narrow the file to the current section.

    Another intriguing approach is to use org-mode to manage your init file:

    That really sounds pretty neat (but I'm sufficiently happy with my current approach that I've never bothered to try it).

    • Phil

      That said, it occurs to me that I do something somewhat similar to the org-babel method in my init file, but I use it purely for notes/links/reference text, and using the more lightweight outline-minor-mode.

      Basically at the top of my init.el I have a large number of notes organised in sections, and I have a local variables block at the end of the file which evals some code to firstly enable (outline-minor-mode) and then (outline-toggle-children) for each heading (where a heading is a line beginning with four semicolons).

      That gives me a small list of headings which I can toggle open and closed as needed with a keystroke, and I'm sure the same approach could trivially be used to deal with all init code in a single file.

      I did this at some point subsequent to splitting my configuration into multiple files, so I think this is the first time it's occurred to me that it could be used to organise the code as well as my notes (but again, I don't have any pressing need to fix something which I don't feel is broken).