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: Should require and provide be symmetrical? Date: Wed, 10 Feb 2010 11:48:34 +0900 Message-ID: <87tytpyfel.fsf@uwakimon.sk.tsukuba.ac.jp> References: <5e3a506e1002091729u3d70ed8bt2350c57b5d480f14@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1265769483 11981 80.91.229.12 (10 Feb 2010 02:38:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 10 Feb 2010 02:38:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Nathaniel Flath Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 10 03:38:01 2010 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.69) (envelope-from ) id 1Nf2Sk-0003pM-Qq for ged-emacs-devel@m.gmane.org; Wed, 10 Feb 2010 03:37:59 +0100 Original-Received: from localhost ([127.0.0.1]:56806 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nf2Sk-0005QG-9C for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2010 21:37:58 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nf2Sf-0005QB-Eu for emacs-devel@gnu.org; Tue, 09 Feb 2010 21:37:53 -0500 Original-Received: from [199.232.76.173] (port=58788 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nf2Se-0005Q2-3W for emacs-devel@gnu.org; Tue, 09 Feb 2010 21:37:52 -0500 Original-Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nf2Sc-0003SE-Lr for emacs-devel@gnu.org; Tue, 09 Feb 2010 21:37:51 -0500 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:34186) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nf2Sc-0003S0-8O for emacs-devel@gnu.org; Tue, 09 Feb 2010 21:37:50 -0500 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 F2FDA1535A8; Wed, 10 Feb 2010 11:37:47 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id E8EC31A37B7; Wed, 10 Feb 2010 11:48:34 +0900 (JST) In-Reply-To: <5e3a506e1002091729u3d70ed8bt2350c57b5d480f14@mail.gmail.com> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" a03421eb562b 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:121044 Archived-At: Nathaniel Flath writes: > I came across a problem with require and provide that seems rather > counterintuitive, although it is implicit in the documentaiton. If one file > provides a feature with (provide 'feature) and another requires it, there is > no guarantee that that specific file is loaded, even if no other file calls > (provide 'feature). How do you propose that Emacs would know this? N.B. In general there are usually at least two files that provide any feature (the .el and its corresponding .elc). > I ran into this whil splitting up my personal configuration - I was > attempting to mirror the packages I was loading, so for example > org.el in my directory would contain customizations for org-mode. > However, in this file, a (require 'org) would cause an infinite > require error, as it tried to load itself instead of the org.el in > emacs. Should this behaviour be changed, or is there a reason for > it? You'd have to change the loader to parse the file without loading it. Yuck. Then, if you get a provide error, you have to keep walking the load-path to the very end in hopes of find one that does do a provide. This is still (Big-O (length load-path)), but your coefficient has been pessimized. Yuck. And now we have to maintain state for error- reporting (a list of tried-and-failed org.el and org.elc files). Double-yuck. So, no, I can see no positive reason for the behavior, but I can see lots of reasons not to change the implementation. If I were you, I'd just put those configs somewhere that isn't on load-path.