From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tim X Newsgroups: gmane.emacs.help Subject: Re: An alternative to a monolithic ~/.emacs init file Date: Tue, 13 Nov 2007 20:26:31 +1100 Organization: Posted via Supernews, http://www.supernews.com Message-ID: <87wssm4htk.fsf@lion.rapttech.com.au> References: <1194455637.485972.177570@s15g2000prm.googlegroups.com> <1194544126.425679.261670@e9g2000prf.googlegroups.com> <1194697099.703581.205890@i38g2000prf.googlegroups.com> <1194794977.329113.117040@s15g2000prm.googlegroups.com> <8764075ds7.fsf@lion.rapttech.com.au> <1194927694.712025.269720@v23g2000prn.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1194946960 12463 80.91.229.12 (13 Nov 2007 09:42:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 13 Nov 2007 09:42:40 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Nov 13 10:42:45 2007 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1IrsI4-0001sC-O7 for geh-help-gnu-emacs@m.gmane.org; Tue, 13 Nov 2007 10:42:41 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IrsHs-0007lX-Jh for geh-help-gnu-emacs@m.gmane.org; Tue, 13 Nov 2007 04:42:28 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!sn-xt-sjc-03!sn-xt-sjc-07!sn-xt-sjc-09!sn-post-sjc-01!supernews.com!corp.supernews.com!not-for-mail Original-Newsgroups: gnu.emacs.help User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) Cancel-Lock: sha1:PEYgLQbAdcgR5T0X+5p3QsK74LM= Original-X-Complaints-To: abuse@supernews.com Original-Lines: 82 Original-Xref: shelby.stanford.edu gnu.emacs.help:153757 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:49203 Archived-At: rustom 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