From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: William Xu Newsgroups: gmane.emacs.devel Subject: Re: Is (provide 'foo) at the start good or bad? Date: Fri, 12 Jun 2009 08:01:32 +0300 Organization: the Church of Emacs Message-ID: <21glski6hwpf.fsf@gmail.com> References: <21glws7jx732.fsf@gmail.com> <87r5xqw0s8.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1244783047 9211 80.91.229.12 (12 Jun 2009 05:04:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Jun 2009 05:04:07 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 12 07:04:02 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MEyvp-0006kT-IF for ged-emacs-devel@m.gmane.org; Fri, 12 Jun 2009 07:04:01 +0200 Original-Received: from localhost ([127.0.0.1]:58432 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEyvm-0003yv-0u for ged-emacs-devel@m.gmane.org; Fri, 12 Jun 2009 01:03:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MEyvA-0003p3-1g for emacs-devel@gnu.org; Fri, 12 Jun 2009 01:03:20 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MEyv4-0003mP-Bv for emacs-devel@gnu.org; Fri, 12 Jun 2009 01:03:18 -0400 Original-Received: from [199.232.76.173] (port=57565 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MEyv3-0003mE-SI for emacs-devel@gnu.org; Fri, 12 Jun 2009 01:03:13 -0400 Original-Received: from main.gmane.org ([80.91.229.2]:33854 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 1MEyv3-0004wa-7E for emacs-devel@gnu.org; Fri, 12 Jun 2009 01:03:13 -0400 Original-Received: from list by ciao.gmane.org with local (Exim 4.43) id 1MEyux-0002Pk-0H for emacs-devel@gnu.org; Fri, 12 Jun 2009 05:03:07 +0000 Original-Received: from 62.237.32.162 ([62.237.32.162]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jun 2009 05:03:06 +0000 Original-Received: from william.xwl by 62.237.32.162 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 12 Jun 2009 05:03:06 +0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 92 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 62.237.32.162 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.91 (windows-nt) Cancel-Lock: sha1:fxCOlFzpNn3Uc1LP6H1W1C6x8H4= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:111445 "Stephen J. Turnbull" writes: > Leo writes: > > > > one less char). So what is the benefit of providing it at the very > > > start? > > > > I have run into this problem before. I prefer putting provide at the end > > of the file. > > Putting the provide form at the beginning allows mutually recursive > requires to succeed. I also prefer it as a matter of style, sort of > serving as a `declare-package'. That makes sense. But looks like doesn't work very well? I tried the following: a.el ==== (provide 'a) (require 'b) (defun a-hi () ) (b-hi) b.el ==== (provide 'b) (require 'a) (defun b-hi () ) (a-hi) Put them under load-path, now if I try (require 'a), i got: ,---- | Debugger entered--Lisp error: (void-function a-hi) | (a-hi) | eval-buffer(#> nil "q:/.emacs.d/site-lisp/b.el" nil t) ; Reading at buffer position 55 | load-with-code-conversion("q:/.emacs.d/site-lisp/b.el" "q:/.emacs.d/site-lisp/b.el" nil t) | require(b) | eval-buffer(# nil "q:/.emacs.d/site-lisp/a.el" nil t) ; Reading at buffer position 27 | load-with-code-conversion("q:/.emacs.d/site-lisp/a.el" "q:/.emacs.d/site-lisp/a.el" nil t) | require(a) | eval((require (quote a))) | eval-last-sexp-1(nil) | eval-last-sexp(nil) | call-interactively(eval-last-sexp nil nil) `---- So this doesn't really resolve the recursive requires? > Regarding work-arounds, I would do the OP's task (customizing a > variable) in a mode-hook using `add-to-list', rather than as an > eval-after-load. Unfortunately, ffap has no such hook available, and it is not a mode. add-to-list itself recommends eval-after-load at some point somehow: ,----[ C-h f add-to-list RET ] | add-to-list is a compiled Lisp function in `subr.el'. | | (add-to-list LIST-VAR ELEMENT &optional APPEND COMPARE-FN) | | Add ELEMENT to the value of LIST-VAR if it isn't there yet. | The test for presence of ELEMENT is done with `equal', | or with COMPARE-FN if that's non-nil. | If ELEMENT is added, it is added at the beginning of the list, | unless the optional argument APPEND is non-nil, in which case | ELEMENT is added at the end. | | The return value is the new value of LIST-VAR. | | If you want to use `add-to-list' on a variable that is not defined | until a certain package is loaded, you should put the call to `add-to-list' | into a hook function that will be run only after loading the package. | `eval-after-load' provides one way to do this. In some cases | other hooks, such as major mode hooks, can do the job. `---- -- William http://xwl.appspot.com