From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: rustom Newsgroups: gmane.emacs.help Subject: Re: An alternative to a monolithic ~/.emacs init file Date: 8 Nov 2007 11:53:08 -0800 Organization: http://groups.google.com Message-ID: <1194544126.425679.261670@e9g2000prf.googlegroups.com> References: <1194455637.485972.177570@s15g2000prm.googlegroups.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: ger.gmane.org 1194554446 19865 80.91.229.12 (8 Nov 2007 20:40:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 8 Nov 2007 20:40:46 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Nov 08 21:40:50 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 1IqEBD-0003vm-PD for geh-help-gnu-emacs@m.gmane.org; Thu, 08 Nov 2007 21:40:48 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IqEB2-00083i-4J for geh-help-gnu-emacs@m.gmane.org; Thu, 08 Nov 2007 15:40:36 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!postnews.google.com!e9g2000prf.googlegroups.com!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 49 Original-NNTP-Posting-Host: 59.95.22.199 Original-X-Trace: posting.google.com 1194551615 7648 127.0.0.1 (8 Nov 2007 19:53:35 GMT) Original-X-Complaints-To: groups-abuse@google.com Original-NNTP-Posting-Date: Thu, 8 Nov 2007 19:53:35 +0000 (UTC) In-Reply-To: User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.4) Gecko/20070508 Iceweasel/2.0.0.4 (Debian-2.0.0.4-0etch1),gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: e9g2000prf.googlegroups.com; posting-host=59.95.22.199; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Original-Xref: shelby.stanford.edu gnu.emacs.help:153622 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:49084 Archived-At: On Nov 8, 6:08 pm, Sebastian Tennant wrote: > Quoth rustom : > > > Could you please elaborate on how this works a little? [...] I really > > would like to have a tiny little .emacs file and a bunch of files and > > directories containing unrelated stuff > > If you don't care about autoloads (or you're not sure what they are) and > you just want a small ~/.emacs, then all you need is this: > > ;;; load dotemacs/*.el > (mapc (lambda (f) (load f)) > (split-string > (shell-command-to-string "find ~/elisp/dotemacs -name *.el"))) > > This routine simply loads each file ending '.el' found under the > directory ~/elisp/dotemacs. > > Sebastian Thanks. I think I understand autoload. Also I dont want needless loading at emacs-startup -- its unlikely that in a given session I will do C and python and ruby and org and tramp and elisp and ..... though I do use all these once in a while. What I dont understand are magic cookies and how emacs uses them; or more correctly *When* emacs uses them. The elisp manual says: >.These comments do nothing on their own, but they serve as a guide for the command `update-file-autoloads', > which constructs calls to `autoload' and arranges to execute them when Emacs is built. Does this mean I have to rebuild emacs if I want to use this ?! Also what I guess is a related question -- What/Where/How is loaddefs.el? It does not seem to be a fixed single file -- value of the variable 'generated-autoloaded-file' because many a package p comes with its own p-loaddefs.el. But then if loaddefs.el is not a single file but a general class of files we are back to the same problem that autoload sets out to solve namely: -- if emacs does not know about feature x it does not know what to do -- if emacs knows about x it does not need to have anything to do In short I can (I think!) understand elisp code (been writing some for 15 odd years) What I am unable to understand is what happens at what binding time: 1. emacs development time 2. emacs (re)build time 3. emacs start time 4. feature (first) reference time