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.