From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Is (provide 'foo) at the start good or bad? Date: Fri, 12 Jun 2009 19:26:24 +0900 Message-ID: <87ljnxwxwv.fsf@uwakimon.sk.tsukuba.ac.jp> References: <21glws7jx732.fsf@gmail.com> <87r5xqw0s8.fsf@uwakimon.sk.tsukuba.ac.jp> <21glski6hwpf.fsf@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1244802257 25035 80.91.229.12 (12 Jun 2009 10:24:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Jun 2009 10:24:17 +0000 (UTC) Cc: emacs-devel@gnu.org To: William Xu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 12 12:24:13 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 1MF3vd-0006qk-LJ for ged-emacs-devel@m.gmane.org; Fri, 12 Jun 2009 12:24:09 +0200 Original-Received: from localhost ([127.0.0.1]:46394 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF3vd-0008Ck-1D for ged-emacs-devel@m.gmane.org; Fri, 12 Jun 2009 06:24:09 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MF3vW-0008BI-6P for emacs-devel@gnu.org; Fri, 12 Jun 2009 06:24:02 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MF3vR-00086i-V8 for emacs-devel@gnu.org; Fri, 12 Jun 2009 06:24:01 -0400 Original-Received: from [199.232.76.173] (port=38126 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MF3vR-00086S-Gr for emacs-devel@gnu.org; Fri, 12 Jun 2009 06:23:57 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:35442) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MF3vR-0001oo-2M for emacs-devel@gnu.org; Fri, 12 Jun 2009 06:23:57 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id DDB071537B8; Fri, 12 Jun 2009 19:23:55 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id DD1671A27C1; Fri, 12 Jun 2009 19:26:24 +0900 (JST) In-Reply-To: <21glski6hwpf.fsf@gmail.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta28) "fuki" 83e35df20028+ XEmacs Lucid (x86_64-unknown-linux) 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:111451 Archived-At: William Xu writes: > That makes sense. But looks like doesn't work very well? I tried the > following: Of course that doesn't work. You've got a dependency loop. In this particular case you can break it by using "just-in-time" requires: a.el: (provide 'a) (defun a-hi ()) (require 'b) (b-hi) b.el: (provide 'b) (defun b-hi ()) (require 'a) (a-hi) but that won't always work. However, this: a.el: (require 'b) (provide 'a) b.el: (require 'a) (provide 'b) is already an infloop. Bottom line: In mutually recursive requires, provide at the top gives you rope. You can knit a hammock and enjoy life, or knot a noose and die. Your choice. Provide at the bottom is an obtuse way to find out how much memory you have. No choice. On the other hand you do have the original problem that eval-after-load will not necessarily work right. This is basically the same issue, though, and probably needs to be fixed by refactoring eventually. Using a mode-activation hook is one such refactoring, although it doesn't work in this case. > 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: (eval-after-load ;; eventually fails silently if the list-variable was never defined ;; probably not what you want (when (boundp 'list-variable) (add-to-list 'list-variable element-to-add))) or (eval-after-load ;; eventually fails loudly if the list-variable was never defined ;; probably what you want (unless load-file-name (add-to-list 'list-variable element-to-add))) might work, but I forget the original context. Of course Alan is correct, there is no one right way, and you might consider the "cures" above worse than the "disease".