Xah Lee, ,
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.
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 a single file, 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:
(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, e.g. {basic, keybindings, load_packages, elisp_functions, ms_windows, misc}.
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, call byte-compile-file. Or, dired into the buffer, mark the “.el” files, then press B (dired-do-byte-compile).
For many small customization code, such as setting font, variable, hooks, personal keybindings, byte compile doesn't make any noticeable difference.
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 problem with compiling init files is that, if you edit a file, you need to remember to compile it again, else emacs will just load the compiled version that doesn't have your changes.
Here's a useful code to add. It'll automatically byte compile a file when it's saved, but only when a byte-compiled file already exists.
(defun auto-recompile-el-buffer () (interactive) (when (and (eq major-mode 'emacs-lisp-mode) (file-exists-p (byte-compile-dest-file buffer-file-name))) (byte-compile-file buffer-file-name))) (add-hook 'after-save-hook 'auto-recompile-el-buffer)
See: What's Emacs Custom System and Should You Use It?.
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 is 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.