Xah Lee has an interesting post on organizing your emacs init file in which he advocates breaking your .emacs or init.el file into several subfiles. Generally when people do this they organize the subfiles by category or function—all the items concerned with processing C files, for example, would be in their own subfile—and Lee is in favor of this approach. But even more, he says it’s a win to just arbitrarily break your .emacs or init.el into equal parts based simply on length.
I understand the urge to segregate individual functionality into separate files but I’ve never been able to warm up to the idea. My init.el file is a little over 800 lines, probably making it of medium length in the universe of such files. According to Lee and others who like to break their configuration files up, this makes me a prime candidate for using subfiles.
I sort of do that by organizing my init.el into subsections within the single file but I don’t see the case for multiple files. It seems to me that it’s just harder to find things that way and because I’m always tweaking my init.el I almost always have it open it Emacs. That would be more of a pain if I had to keep several subfiles open all the time. Still, I recognize that this is largely a matter of preference and don’t insist that my way is right or better; it’s just my way.
The really interesting thing about Lee’s post is a bit of Elisp that he gives to automatically byte compile your .emacs or init.el file when it’s saved after being changed. The code checks to see if a .elc exists and if so recompiles the init file. I’ve seen other solutions that do the same sort of thing but they all fell just a little bit short. The nice thing about Lee’s solution is that you can easily modify it to do exactly what you need.
Regardless of your position on multiple Emacs init files, Lee’s solution for automatically compiling this file or files makes his post worth a read.
hi Jon, your blog is very well written, highly informative, and supportive of others. Due to your blog, it helped me getting a wider exposure in emacs community. Thank you very much!
I have a tiny init.el file that sets up my load path and then loads an org-mode file (startup.org) using org-babel-load-file. It’s smart enough to regenerate startup.el only when startup.org changes, and just load startup.el directly the rest of the time. It doesn’t automatically byte-compile startup.el, but that may just be an option I haven’t found yet. :-)
I live in org-mode (ever since my Mom kicked me out :-) so it’s very convenient for my startup file to be in the same format.
I share you enthusiasm for org-mode and have sometimes considered doing what you do but inertia keeps me using the traditional method.
It did for me, too, until curiosity got to the better of me. My initial attempt was just a three-line wrapper around my original init:
* init.el
#+begin_src emacs-lisp
(entire contents of init.el plopped here)
#+end_src
Entirely useless in itself, but I slowly reorganized it from there.
I think everybody should take a look at John Wiegley’s .emacs configuration. I’m currently implementing the use-package and bind-key functions into my init.el, and it is truly amazing how quickly Emacs fires up for me. It’s not for everybody, but there are a lot of magnificent elisp lessons to be learned just reading through the initialization files.
I wholeheartedly second this recommendation. Wiegley’s got a ton of useful ideas in his configuration. In case you missed it, be sure to see Wiegley’s chat with Sacha Chua. I wrote about that here and here. There are pointers to the chat and its transcript at the above links.
Im a big fan of splitting the .emacs, to use your example I only care about C specific configuaration files, when editing C code, so having the right files open isnt that bigger deal to me.
Splitting by file size seems a bit silly to me, I try and split them a bit more naturally then that.
My actual .init.el is less then a screen of code thou, its more a launcher/init control flow then anything, and is designed to be pretty dynamic at growing to new files
I’m also a big fan of using multiple files, logically grouped. I have C-h C-l bound to find-library, so jumping to my code is as simple as (for example) C-h C-l my-keybindings RET