Not too long ago I found my emacs customizations were out of control. Over some time I had kept adding imports and configuration of various libraries and I was having trouble keeping track of it all. Some libs had been added for trial purposes and managed to overstay their welcome. Others were there because of dependencies or some other reason which I could no longer remember. I was being a good programmer and had things modularly split up among several files. But as new library versions came out, dependencies changed and I encountered the need to use emacs on multiple computers, it became a mess.
So one day I decided to just nuke all my customizations and start again from scratch. This time I managed all my customization files and key libraries in source control. This coupled with machine specific customizations allowed me to easily have a decent customized environment on whatever machine I needed to be working on at the moment.
Another thing I did was to actually consolidate most of the customization into my dot emacs. It's actually the antithesis of what Ola Bini is prescribing in a recent blog post, but my experience has been that splitting up most of the customization code caused a bigger management nightmare than any benefit I got from modularization.
So now, my dot emacs has common customizations followed by customizations based on how emacs was run (tty, X11, etc.) and lastly, customizations based on the hostname that I'm on. Here are some tips that I'll pass along.
- Use the message function to log what was loaded. These messages will show up in your
*Messages*buffer and make it really easy to tell where things went wrong if you have a bug in one of your customizations.
(message "applying comment settings ...")
- Define an add-path function (thanks to Ola for the idea) and add library dirs to your load-path right with the library. I used to have a section near the top where I would list all the library dirs that I wanted in the load-path as Ola shows in his blog page. But when I changed versions of a library I would have to modify two sections of my file -- one where I specified the lib dir and a second place somewhere else where I was actually loading and customizing the library. Nowadays I prefer to keep everything related to a particular library in one place so it's easy to disable or upgrade. For example, here's a portion of my yasnippet customization.
(setq custom-basedir (expand-file-name "~/.emacs.d/")) (defun add-path (p) (add-to-list 'load-path (concat custom-basedir p))) (message "loading yasnippet customizations ...") (add-path "yasnippet-0.2.2") (require 'yasnippet)
- Use yasnippet for standard templates of things you do quite often. I can't say that I miss Textmate much anymore.
- Use the
system-namevariable to help you define host specific customizations.
- Use the
window-systemvariable to provide window specific customizations. For example if I'm running emacs in X, then I'll enable color themes and use a nice looking theme. But if the window system is mac or I'm running in a tty, then I'll just set the foreground and background colors to white and black respectively.
- Create a Makefile, Rakefile, etc. to publish your version controlled files to their respective locations. Originally I tried to version control files in their deployed positions, but I found that hard to manage. Now I just check out the files from the repo and run the makefile to push the files into their proper places. It also handles renaming dot-emacs.el to .emacs.
- If you work with multiple projects having similarly named files, use uniquify and set the name style for reverse. That way the buffer name will be filename/path.
(require 'uniquify) (setq uniquify-buffer-name-style 'reverse)
- Make sure to create a project on github to manage your emacs customizations and give others an opportunity to fork your config and send you patches. Okay, I'm actually joking about this one ... what's up with all of these emacs config projects? Don't these people have any other source management system? I especially like Stu's description for his emacs config project, "Everyone else has a private emacs world, so why not me?"
Good post! One question though: Have you compared yasnippet with msfAbbrev? It seems like yasnippet is better, what is your opinion? One downside seems to be that it requires an extra key stroke (tab) to activate, whereas msf activates directly just as the ordinary abbrevs.
Also, try (setq uniquify-buffer-name-style 'post-forward-angle-brackets). I think that's the best setting.
I'd like to follow-up to the earlier commenter. How did you choose the template package you use? I have a bunch of old tempo templates lying around. Should I recode them? How would I choose which templating system to use?
Thanks for any advice!
Regarding msfabbrev v. yasnippets - you can change the yasnippets activation key
(setq yas/trigger-key (kbd "SPC"))
> what's up with all of these emacs config projects?
I regularly send people on IRC links to my dotfiles when I need to show an example of a certain technique or point out a particularly useful function. For a while I was doing this with Trac, and then with gitweb, but Github is a much nicer experience overall.