Re: customize versus own expressions in .emacs

[Tim X]

Sebastian Luque <sluque@mun.ca> writes:


> Since I began using Emacs a little over a year now, I've been mixing my
> own entries with those made by the Customize interface in my ~/.emacs. As
> I learned more and started using more libraries, it has become more
> difficult to maintain this file due to the mixing of the two styles.
> However, I'm not sure which approach to take in the long run; the
> Customize interface is ideal for initially setting options, because you
> can look at all the available options at once. OTOH, having a section with
> my own expressions in the file is much better for keeping track of
> everything afterward.
>
> Something similar to this was discussed in this list ("is Customize the
> right advice to give?") back in 1999. Variation in preferences was very
> large. Is there some general consensus regarding this today, given that
> Customize seems to have improved since 1999?
>

What I found works well for me is to put a bit of elisp at the
beginning of my .emacs file which tells emacs to look in my own
.emacs.d directory and load the files in that directory. I then can
break up all my own customization code into individual files within
this directory, which makes it easy to temporarily remove a
customization or add new ones. The side effect of doing this is that
my .emacs file only contains one bit of elisp code and the 'customize'
settings. 

Prior to adding the bit of elisp, I took an even simpler approach
where I added my .emacs.d directory to the load path and then put
(provide 'my-xxx)  lines in all my setup files. Then I'd have lines like

(require 'my-gnusconf)
(require 'my-vmconf)

in my .emacs file to load each of my config files. 

both methods worked fine. However, I like the version I have now with
the function to load the files as it provides better debuggin/tracking
mechanisms. If some new change causes a problem with .emacs and you
get the "Cannot load .emacs" error at startup, you can identify which
is the offending file slightly more easily than you can using the
require/provide approach. The require/provide approach has the
advantage that your configs won't be loaded more than once (which can
have unexpected side effects) should you decide to re-load .emacs

Tim
-- 
Tim Cross
The e-mail address on this message is FALSE (obviously!). My real e-mail is
to a company in Australia called rapttech and my login is tcross - if you 
really need to send mail, you should be able to work it out!