Organize Your .emacs in 5 Minutes

Perm url with updates:

Organize Your .emacs in 5 Minutes

Xah Lee, 2010-04-03

This article shows you a quick way to organize your emacs init file.

Most emacs users, have tens or hundred lines in their emacs init file, accumulated over the years. Large emacs init files 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 a lots times 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.

Split Your .emacs into Multiple Files

When you need something, you pile it in your “.emacs” and you can immediate 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.

Rename File When Needed

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 creat new files and name it properly, such as “emacs_init_critical”, “emacs_init_elisp_functions”, “emacs_init_keybindings”, “emacs_init_mswin”, “emacs_init_home”.

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.

Byte Compile Optionally

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” like this “(load "emacs_init_1")”, emacs will first try to load the byte compiled version “emacs_init_1.elc” first. If it doesn't exist, then emacs will try to load “emacs_init_1.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.

Compile Packages

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.)

Limit To 5 Minutes!

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 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 some consistent style. Each time you mod your init file, 5 min becomes 10 min, then you thought “O, but maybe now i should do this”, and the time spend on this often becomes 30 minutes, 1 hour.

Need Based

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: Xah Lee's Emacs Customization File.

Popular posts from this blog

11 Years of Writing About Emacs

does md5 creates more randomness?

Google Code shutting down, future of ErgoEmacs