Xah Lee, 2010-04-03
This article shows you a quick way to organize your emacs init file.
Many emacs users, have hundreds of lines in their emacs init file, accumulated over the years. Large emacs init file makes emacs starting slow, and is a problem when you upgrade emacs, or install a new package.
So, how do you organize it? When it comes to organization, many of us, probably think it'll take lots of time and discipline, or with some special principle, system, to keep the “.emacs” file clean. From what i've seen in the past decade, vast majority of emacs users simply have one huge messy pile of stuff in “.emacs”, and this situation often is cited as their reluctance to upgrade to the latest emacs release.
Personally, i find that elaborate rule or system or time spend on organizing emacs init file is actually not productive.
When you need something, you pile it in your “.emacs” and you can immediately go back to work on things you need done. That is the beauty of it. The best way i find in keeping “.emacs” organized, is just to break them into 2 or more files and spend no more than 5 minutes doing it. Here's how i do it.
Go to your “.emacs”. If the file has more than say 2 hundred of lines, then just go to the middle and split the file into 2 files. Say, name it “emacs_init_1.el” and “emacs_init_2.el”. The exact file name doesn't matter. Then, in your “.emacs”, change it to like this:
; my emacs customization (load "emacs_init_1") (load "emacs_init_2")
That's it. The key to keep in mind is that you should not spend more than 5 minutes on this. If you spend more, you are likely being less productive than you could've been.
When next time you have more code you want to add, just pick a file and add there. Each time, spend no more than 5 minutes doing it.
Within that 5 min, you can shuffle the file content a bit. For example, moving some important customizations into one file, less important ones into the other. Also, you are free to create new files and name it properly, such as “emacs_init_critical”, “emacs_init_elisp_functions”, “emacs_init_keybindings”, “emacs_init_load_packages”, “emacs_init_ms_windows”, “emacs_init_home_config”.
This way, you have your “.emacs” under manageable condition, without much effort. You may edit your “.emacs” once a month, or if you are a heavy emacs experimenter, perhaps once a week. Gradually over the years, you may have multiple emacs init files, all manageable and reasonably organized.
If you want, you can compile the elisp files to make it load AND run faster. (a compiled elisp will not only load faster, but the functions/commands will run about 6 times or more faster.)
To compile, just type 【Alt+x byte-compile-file】.
Note that when you use (load "myfile"),
emacs will first try to load the byte compiled version
“myfile.elc” first. If it doesn't exist, then emacs will try to
load “myfile.el”.
On flaw with compile is that, if you ever edited or added new code, you need to remember to compile it again, else emacs will just load the compiled version that doesn't have your changes.
When you downloaded some elisp package, usually you want to byte compile it. Other than that, little things like font changes, variable changes, hooks, personal keybindings, or other minor settings, byte compile doesn't make any noticeable difference. Personally, i have all packages byte compiled, but otherwise my init files are not byte compiled, because it is a pain to remember to byte compile it again after edit. (some emacs fan has cooked up schemes to have emacs automatically byte compile a file after edit… but for me that's getting more complicated and not really needed.)
Again, my experience is that you should not fret about it. Some type of coders, like me, tend to think of some beautiful organization scheme. For example, you can organize the files by importance, or by OS (Linux, Windows, Mac) for those using multi OSes, or you can organize by work vs home, or organize by machines you have access, or organize by the type of customization (e.g. keybindings, UI changes (font, frame, window position, background color), functions, type of packages…), or, you might start to rewrite the code so that they are all in some consistent style. Each time you mod your init file, 5 min becomes 10 min, then you thought “O, but maybe now re-factor this into components”, and the time spend on this often becomes 30 minutes, 1 hour.
What i find the most effective, is simply a need based one. If i started to spend more than 5 min on modding my init file, i ask my self “do i really NEED to do this?”. If no, i stop and let things be. Until someday, when i have some extra time to study emacs for the sake of studying, then i may choose to spend time with my emacs init files, looking into what are there, which's important, how the code works, etc. Most likely, there are many other areas in emacs one can study more fruitfully than fretting with getting init files into a pristine condition.
PS my init files are here for those curious: Xah Lee's Emacs Customization File.