Re: An alternative to a monolithic ~/.emacs init file

[Tim X]

rustom <rustompmody@gmail.com> writes:

>> Note that your 'fix' i.e. putting a (provide 'sb.info) is only hiding the
>> problem and not actually fixing it. If your running emacs 22 and still have
>> a stand-alone version of speedbar installed, you could just remove the
>> stand-alone version.
>>
>> Tim
>
> Just tried this. Evidently ecb has a dependency to speedbar.  So
> removing speedbar means removing ecb.
> Anyhow went ahead with this assuming that in emacs 22 these things are
> in the base install.
> This removed cedet-contrib, cogre, ecb, ede, semantic and speedbar
> Now ecb does not work. speedbar standalone works but that is really
> ugly compared to ecb.
>
> I am running emacs-snapshot-gtk under debian etch
> M-x version gives GNU Emacs 22.1.50.1
>

Ah, yep, your running into one of the issues with using a distro packaging
system. Packages like ecb depend on a stand alone speedbar package (as do
the others you listed, but don't know about speedbar now being packaged in
emacs itself. I'm not sure if you could use the force option to apt to
install ecb or not. The other issue may also be that I think the bundled
speedbar version in emacs 22 is older than the version in the stand alone
package (at least, this was the case some time back before emacs 22 was
released.)

>From memory, when I looked at this the problem was emacs getting confused
due to mixups in the emacs bundled speedbar .el files and the ones that are
part of the stand alone version. Due to changes in these files, a circular
dependency arises where one file 'requires' the second file and the second
file 'requires' the first one. 

I'm very surprised your (provide 'sb-info) works though. Essentially, by
putting a provide statement into your file tells it that the definitions
have been loaded and there is no need to load the file. I would have
thought this would break things as the file has not been loaded (unless its
somehow loaded somewhere else). 

I'd check the bug reports for ecb - its likely a bug has been reported and
there could be a better fix provided. Alternatively, it may be possible to
get around the issue by re-jigging load paths so that a more consistent
behavior occurs. 

On your original question regarding breaking up your .emacs. I've taken a
very simple approach, but it works really well for me. 

All my customizations apart from the auto-generated 'custom' sections are
in their own files (broken up into groups of functionality). At the end of
each file, I just put a (provides blah). All the files are in ~/.emacs.d
I add the directory to my load path in .emacs and then just have (require
'blah)  line for the things I want loaded. 

This means my .emacs consists of only a couple of add-to-list statements
that add to my load-path and lines of require statements followed by the
customize section. 

What I like about this approach is that if I want to stop loading some bit
of my extensions, I just comment out the appropriate require line. I find
this quick and simple. Its only downside is that I have to edit my .emacs
to stop one of my extensions from being loaded. 

Originally, I used a system that was very similar to the way Debian loads
its various setup files from /etc/emacs/site-start.d et. al. This wasn't
bad because I could change what was loaded by simply moving the file out of
my .emacs.d directory and didn't need to edit the .emacs file. However, I
ended up dropping this approach, but to be honest, can't remember why. 

There is also the initz emacs package. This package allows you to split
your emacs config over various files, can control what is loaded based on
the version of emacs you are running and had some other fairly advanced
features. However, it was a bit overly complex or over engineered for my
needs. Probably very good if your someone who uses emacs and xemacs at the
same time.

tim

-- 
tcross (at) rapttech dot com dot au