Thoughts on Emacs Configuration

I sometimes feel that I have the most unorganized Emacs configuration strategy imaginable. I don’t worry about autoloading or other quick-loading strategies and I throw my entire configuration (other than machine and OS specific items) into my init.el file. All the really cool guys have their configurations broken out into separate files, carefully optimized for the smallest possible loading time.

I was, therefore, happy to discover that I’m not alone. Selah not only has the same strategy but argues that it’s the correct strategy. He used to obsess over Emacs loading times like the rest of us but realized that he spent far more time tweaking his configuration for optimal load time than he did waiting for it to load. That’s because like most of us he didn’t load it very often. He says he loads it only about twice a week. Even that seems like a lot to me. My Emacs instances generally run from a week to a month before I reload it because I get into an error condition or need to refresh a package. Reloading takes me about 5 seconds so it makes no sense worrying about reducing the time—except maybe as an interesting engineering problem.

Selah says that he likes everything in a single file because he doesn’t have to spend time remembering where things are as he did when he had everything broken out to multiple files. I like keeping everything in a single init.el for the same reason. Yes, you can locate things reasonably quickly with some form of grep or indexing (such as a TAGS file) but as Selah notes, that means you have to perform a context switch and think about something besides the problem you’re solving. The other advantage of having a single file is that it makes it easy to convert it to an annotated Org file. I haven’t done that yet but it’s on my TODO list.

UPDATE [2016-11-29 Tue 10:17]: Correct post’s author.

UPDATE [2016-11-30 Wed 12:41]: iniitinit.

This entry was posted in General and tagged . Bookmark the permalink.
  • I keep everything in one org file and load it using org-babel-load file. And I've recently started running Emacs as a systemd service so it load my config at login. So now when I `emacsclient -c` a new frame pops up instantly.

    THEN I stopped caring about optimizing load times.

  • Fran Burstall

    I am with you here: just emacs --daemon and one init.el . It is not even a mess anymore thanks to the very wonderful use-package.

  • Phil

    I don't care about having the smallest possible loading time, but I do use autoloads and eval-after-load as a standard practice. Switching from require-ing libraries to loading them on demand can make a huge difference to start time -- and once you've converted your existing config, it's trivial to keep using that practice whenever you add new libraries.

    I don't believe there's a right or wrong approach, though.

    If you start an Emacs daemon at boot time and only need that one instance, the you can argue that pre-loading all the things you're likely to need to load makes Emacs faster (so far as the user is concerned).

    I do have long-running Emacs instances (sometimes months on end), but I also frequently run additional instances (often on different servers), and so for my use cases a relatively quick start time is very beneficial.

  • Jens Lange

    I use Emacs for a year now. As Alex I use org mode containing lisp blocks that are loaded by org-babel. So I have the most configuration in one file organized by org mode which is lot more overseeable than a large flat file. I say the most because some parts were put in other files but for good reason. First I have an init.el. This defines just the package-archives and the files to load next for easy decoupling. The custom.el stops the cluttering from the custom system and finally a file called contains the installation specific configuration parts like ibuffer groups, personal details, org agenda files, etc. This allows me to keep configurations in sync easily across systems intended for different purposes.

    Use package is my hate-love. On one hand it's a great container for package configuration parts on the other hands it destroys my org system. For example I have a keymappings section. The idea was to look at one place for all the keymappings. This does not work when using use-package (as intended). My settlement was to use use-package only for external packages.

    In regards of load times: Ignoring them is the correct way. Just built a new PC and emacs got lightning fast. So the problem will evaporate with time. On the other hand there might be packages that misbehave and take let's say eight seconds to load. Use-package verbose mode allows you to see that. Then you can troubleshoot or replace these packages. You could call this optimzation but doing this is more troubleshooting than optimization. Using the defer option in use packages is just adding one line and useful for every mode that is used rarely and only on demand.

  • I have never cared about load times, but I am finding that managing cruft is important. Your init file needs occasional weeding, pruning and care from time to time or it becomes a mangled nightmare that is impossible to debug. Entropy is a bitch. This is now more important than ever since emacs releases now occur multiple times within any given dog's average life expectancy :) A long time ago, an emacs release outlived the Saint Bernard we had when living in Hong Kong.

    I am slowly moving towards moving from a single .emacs file that eventually be all in org mode. I'm about 2/3 of the way through moving nearly everything to use package in a separate file. The monster config I use for helm is only half moved, and I keep breaking things.

    It's worth it, the use package system makes it easier to understand how things are set up and know when and where things are and why they are set up that way.

    I think in the end I will only have four files, init, init-org, init-mu4e and init-helm and perhaps one other file that will hold any autoconfig nonsense that is done without telling me. This is mportant because I keep all config files in git repos that keep the same setup working across four computers, at two offices and one at home.

    I also just moved from gnus to mu4e after over 10 years using gnus which has allowed me to dump the huge crufty gnus config file. There are still things I miss, but the overall experience is well worth it.

    Still don't know how I will sync the elfeed database across machines without resorting to something akin to dropbox... but it will all work out in time.

  • Small typo: `iniit.el` in the last paragraph.

    • jcs

      Fixed. Thanks.