From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Harry Putnam Newsgroups: gmane.emacs.help Subject: Re: Tracing what is loading Date: Wed, 10 Dec 2008 02:47:10 -0600 Organization: Still searching... Message-ID: <87hc5ca035.fsf@newsguy.com> References: <877i69c12p.fsf@newsguy.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1228898903 7506 80.91.229.12 (10 Dec 2008 08:48:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Dec 2008 08:48:23 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Dec 10 09:49:28 2008 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 1LAKl3-0006eO-58 for geh-help-gnu-emacs@m.gmane.org; Wed, 10 Dec 2008 09:49:25 +0100 Original-Received: from localhost ([127.0.0.1]:41023 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAKjs-0007fv-60 for geh-help-gnu-emacs@m.gmane.org; Wed, 10 Dec 2008 03:48:12 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LAKj8-0007Il-KG for help-gnu-emacs@gnu.org; Wed, 10 Dec 2008 03:47:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LAKj7-0007Hw-RB for help-gnu-emacs@gnu.org; Wed, 10 Dec 2008 03:47:26 -0500 Original-Received: from [199.232.76.173] (port=57115 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAKj7-0007Hk-LF for help-gnu-emacs@gnu.org; Wed, 10 Dec 2008 03:47:25 -0500 Original-Received: from main.gmane.org ([80.91.229.2]:44858 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LAKj7-0003nF-1Y for help-gnu-emacs@gnu.org; Wed, 10 Dec 2008 03:47:25 -0500 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LAKj3-0004Dh-33 for help-gnu-emacs@gnu.org; Wed, 10 Dec 2008 08:47:21 +0000 Original-Received: from c-98-215-178-6.hsd1.in.comcast.net ([98.215.178.6]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Dec 2008 08:47:21 +0000 Original-Received: from reader by c-98-215-178-6.hsd1.in.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 10 Dec 2008 08:47:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 90 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: c-98-215-178-6.hsd1.in.comcast.net User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.3 (gnu/linux) Cancel-Lock: sha1:iSnA6A1S64p/o1KRKiWdFvk2asE= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:60532 Archived-At: Kevin Rodgers writes: [...] >> All are in /usr/share/emacs/22.3* > > I think those were dumped into the emacs executable. > >> Then comes a line (106): >> >> /usr/local/GNUS/lisp/gnus-load.el >> >> An address that is not a normal path to be searched. >> How did emacs know to look there? >> >> That is the address to gnus but not the one in the emacs >> distribution. This is the cvs version. > > Hmmm, perhaps that directory was in load-path at some point, > or the file was loaded using its absolute file name. > >> The information that tells emacs where to look for that lisp directory >> resides in /usr/local/share/emacs/site-lisp/site-start.el >> >> Which according to the list has not yet been loaded. >> >> That doesn't show up until line 118 >> /usr/local/share/emacs/site-lisp/site-start.el >> >> So is this listing just not accurate to that degree or is something else >> going on? I ask because I'm trying to discover when certain init >> files are loaded. > > Does /usr/local/GNUS/lisp/gnus-load.el show up in the list when you > start emacs with -Q? What about the other files between it and > /usr/local/share/emacs/site-lisp/site-start.el? No and site-start.el doesn't either but then they shouldn't with -Q Even with -Q though I do see one anomaly. The whole list (108) lines), with the exception of two lines near the end are all in /usr/share/emacs/22.3. and you've suggested how that happens. /usr/share/emacs/site-lisp/subdirs.el (loads at 102) Again that seams normal enough. And this one is a little puzzling: /home/reader/.abbrev_defs (loads at line 106) But of course ~/.emacs is not loaded with the -Q flag so what instructs emacs to load ~/.abbrev_defs? I thought ~/.emacs was doing that. I do have code there about .abbrev_defs, But as you can see, even with -Q something has caused emacs to load ~/.abbrev_defs. I'm beginning to think my initial thought to track things in the *Messages* buffer is a better place to track init files. The history-list shows the cart before the horse in several instances and the list is cluttered with too much stuff that isn't related to init files. Here is a similar example.. loading emacs without -Q: /anex/usr/local/share/emacs/site-lisp/whats_loading.el (line 110) /usr/local/GNUS/lisp/gnus-load.el (line 111) Both of those things are loaded from site-start.el (I'm pretty sure that's the only place. And the `shadow' list bears that out too. /usr/local/share/emacs/site-lisp/site-start.el (line 119) The history list has site-start.el loading 8,9 lines after 2 items that are only loaded from site-start.el. But looking at the *Messages* output.. things appear in the right order. However, I don't see the init files gentoo developers have stuck in /usr/share/emacs/site-lisp. I think they are loading somewhere before my site-start.el file but neither the history-list or *Messages* shows it. I can probably get to the bottom of it by putting a message in those files or something... still the whole init process is pretty confusing.