From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Kevin Rodgers Newsgroups: gmane.emacs.help Subject: Re: compilation-error-regexp-alist syntax problems Date: Tue, 03 Feb 2004 15:30:32 -0700 Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Message-ID: <40202108.7060308@yahoo.com> References: <401FF0FB.5050008@yahoo.com> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1075847727 25161 80.91.224.253 (3 Feb 2004 22:35:27 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2004 22:35:27 +0000 (UTC) Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Tue Feb 03 23:35:11 2004 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1Ao98R-0005Kr-00 for ; Tue, 03 Feb 2004 23:35:11 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1Ao96K-0001LX-2P for geh-help-gnu-emacs@m.gmane.org; Tue, 03 Feb 2004 17:33:00 -0500 Original-Path: shelby.stanford.edu!newsfeed.stanford.edu!news.tele.dk!news.tele.dk!small.news.tele.dk!fu-berlin.de!uni-berlin.de!170.207.51.80!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 54 Original-NNTP-Posting-Host: 170.207.51.80 Original-X-Trace: news.uni-berlin.de 1075847434 32983486 170.207.51.80 ([82742]) User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 X-Accept-Language: en-us Original-Xref: shelby.stanford.edu gnu.emacs.help:120677 Original-To: help-gnu-emacs@gnu.org X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.help:16625 X-Report-Spam: http://spam.gmane.org/gmane.emacs.help:16625 Stefan Monnier wrote: > > What's untidy about eval-after-load? My only complaint is that it's > > not a macro, so we have to quote the FORM. > > The macro is one such issue indeed: > Instead of (eval-after-load FOO '(progn BAR BAZ)), it should just be > (eval-after-load FOO BAR BAZ). > Do you have a suggestion for how to name such a new macro? How about `defloadforms' or `deflibforms'? > Another issue is that (eval-after-load "compile" FOO) will not run FOO > when loading "compile.elc" or "compile.el" or "/foo/bar/compile", but only > if you load "compile", even if those are all one and the same file. It seems to work if you do (load-library "compile") or (require 'compile), so that issue doesn't bother me too much. But it could complicate things if you're trying to test a new version of "compile". > In Emacs-CVS you can do (eval-after-load 'compile FOO) which will run > FOO right after executing (provide 'compile) which does adress the > above problem, but FOO will be run either before or after loading > "compile", depending on where the `provide' is located in the file > (the coding convention says to put it at the end, but several packages > do not follow the convention). Yes, because that coding convention seems odd to those of us who memorized the Common Lisp mnemonic for managing packages: Put IN Seven EXtremely Random USEr Interface COmmands. I don't understand why it's better to evaluate the FORM immediately after (provide FEATURE) or how that solves Roy's problem of augmenting a list-valued variable defvar'ed in the FILE. The advantage of late evaluation (after the complete FILE is loaded) is that you can reference the default value while computing its new value; the advantage of early evaluation is that other default values can be computed based on this variable's non-default value. To me it's a wash that should probably be decided in favor of allowing the user to access any variable's default value, as when augmenting a list. >>Could it be as simple as adding ;;;###autoload cookies to the 6 >>-regexp-alist `defvar's? > > For this specific problem, it would help. but it will still not fix > the `add-hook' code that Roy used originally. I thought it would result in those `defvar's being copied into loaddefs.el, which would be dumped into the emacs executable, so they could be safely referenced before the "compile" library was actually loaded. What am I misunderstanding? -- Kevin Rodgers