From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.bugs Subject: bug#23638: "load" should use directory from load-file-name as a final fallback Date: Sat, 28 May 2016 10:33:20 -0400 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113d2b82681c490533e7e937 X-Trace: ger.gmane.org 1464446121 14929 80.91.229.3 (28 May 2016 14:35:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 28 May 2016 14:35:21 +0000 (UTC) To: 23638@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat May 28 16:35:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b6fKZ-0005nc-Ht for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 May 2016 16:35:11 +0200 Original-Received: from localhost ([::1]:53393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6fKY-0002dJ-Jt for geb-bug-gnu-emacs@m.gmane.org; Sat, 28 May 2016 10:35:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6fKR-0002c4-Om for bug-gnu-emacs@gnu.org; Sat, 28 May 2016 10:35:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6fKQ-0006o2-NU for bug-gnu-emacs@gnu.org; Sat, 28 May 2016 10:35:03 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:60825) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6fKQ-0006ny-Jg for bug-gnu-emacs@gnu.org; Sat, 28 May 2016 10:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1b6fKQ-0002oF-E8 for bug-gnu-emacs@gnu.org; Sat, 28 May 2016 10:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Robert Weiner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 28 May 2016 14:35:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 23638 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.146444604310719 (code B ref -1); Sat, 28 May 2016 14:35:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 28 May 2016 14:34:03 +0000 Original-Received: from localhost ([127.0.0.1]:44929 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b6fJS-0002mn-T0 for submit@debbugs.gnu.org; Sat, 28 May 2016 10:34:03 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:50491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b6fJR-0002mK-84 for submit@debbugs.gnu.org; Sat, 28 May 2016 10:34:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6fJL-0006Zm-1n for submit@debbugs.gnu.org; Sat, 28 May 2016 10:33:56 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:58211) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6fJK-0006ZT-Uz for submit@debbugs.gnu.org; Sat, 28 May 2016 10:33:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41444) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6fJI-0002Zd-Jv for bug-gnu-emacs@gnu.org; Sat, 28 May 2016 10:33:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b6fJG-0006Z7-IM for bug-gnu-emacs@gnu.org; Sat, 28 May 2016 10:33:51 -0400 Original-Received: from mail-oi0-x22a.google.com ([2607:f8b0:4003:c06::22a]:33166) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b6fJG-0006Z1-CR for bug-gnu-emacs@gnu.org; Sat, 28 May 2016 10:33:50 -0400 Original-Received: by mail-oi0-x22a.google.com with SMTP id k23so214037326oih.0 for ; Sat, 28 May 2016 07:33:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=KSpb7frv0kF9TE0jQ8cv+U0mOGA37+YDUwGyoVYgj3Q=; b=s4ttkZ30kKtalGFebeoQ3p4THua0ol3ctUDOW0H4YAOb9XJyH8dZGezocHC9G4yqgb uzhzPLJiTKRAzXGX97HPe5Jl2c+DYFNfXyjZg+js60lDnzi9PIE7wlGWbGzIzy9Wyjg+ WH/amRvfK3AbmxbsxlS7lBxXY10zfNmcem0+N6YleaQTJ3OBqk0nVr1SUXQ2JWsgJRit wfkU3PqWObk/Xw7rN+9nGvF0K44iuwdv5GY8MHMkx1yR0wlp7s9G6pWXyrSxYHQ7ppRP svssG3yXAMSDrbFFX+NJ1xqWIUObE9mHXknTStkVipjfAabOiiUSdZva9HSjVD0CNFxw GuSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KSpb7frv0kF9TE0jQ8cv+U0mOGA37+YDUwGyoVYgj3Q=; b=WFq0w6qilBBZgF0Va97I0EVTadvtcYc2eb1d9LSKQd7PAKBVUMKoMRb7PHcZkPRmhy rChMS66qDAiVHPlMSsDgUXgDwfS6fvMYhkhgBOM0BSjqcidYXAwIjYOSZppca9dWMI0U Fbe+69+v/z+z4S9nAINXyB6sOUjfi4uZFn8OQrt5l7DfuEKxULUmczO4t3GAyrM+RGD1 k+2dq4fyI2CMjshoYUzDAyzIl+DjT50FVQtkaoXDC6IQmVsQnNArsSg3PMYB6geNwkV/ HYNl9FeHmCBgHI2dbea3j/s21uzKLzQ9TDy5oRuUTtJGogn1rU385Ak5d5jCNUh6+AJu 74Xg== X-Gm-Message-State: ALyK8tJ2hXw4mFODoYRFs9qgnGdlbjg81IAaIzP5/Dg82sirEXnYPfU3scyODAX7zoGLkYSVogNgKodMbb1Mhg== X-Received: by 10.202.224.85 with SMTP id x82mr8994547oig.176.1464446029927; Sat, 28 May 2016 07:33:49 -0700 (PDT) Original-Received: by 10.202.205.17 with HTTP; Sat, 28 May 2016 07:33:20 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:118807 Archived-At: --001a113d2b82681c490533e7e937 Content-Type: text/plain; charset=UTF-8 The "load" function could do more of the right thing in the case where an absolute path is given in a load call and then within the file loaded, require or load references are made to relative files whose directories are not in load path but the files do exist within the directory specified by the original load. So for example, we have a testing directory, "/tmp/" not in load-path with files a.el and b.el. In a.el, there is the line: (require 'b) and then we do a (load "/tmp/a.el"). The require of b will fail but since load-file-name is set to /tmp/a.el, if no matches are found in load-path, it would be a simple matter to try to resolve b in the directory specified in load-file-name as a fallback. This would help in many cases when experimenting with new directories of code that have not yet been added to the load path. It also would help the Emacs package system since it adds only the top-level directory of a package to load-path when trying to byte-compile the package. If the package contains subdirectories, which require or load local files within these subdirectories, these will fail right now but would succeed with the above change. Any comments, suggestions or issues with this? Please consider implementing this and help make multi-directory packages a reality. --001a113d2b82681c490533e7e937 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The "load" function could do more of the right t= hing in the case where an absolute path is given in a load call and then wi= thin the file loaded, require or load references are made to relative files= whose directories are not in load path but the files do exist within the d= irectory specified by the original load.

So for example,= we have a testing directory, "/tmp/" not in load-path with files= a.el and b.el.
In a.el, there is the line: (require 'b) and = then we do a (load "/tmp/a.el").=C2=A0 The require of b will fail= but since load-file-name is set to /tmp/a.el, if no matches are found in l= oad-path, it would be a simple matter to try to resolve b in the directory = specified in load-file-name as a fallback.

This wo= uld help in many cases when experimenting with new directories of code that= have not yet been added to the load path.=C2=A0 It also would help the Ema= cs package system since it adds only the top-level directory of a package t= o load-path when trying to byte-compile the package.=C2=A0 If the package c= ontains subdirectories, which require or load local files within these subd= irectories, these will fail right now but would succeed with the above chan= ge.

Any comments, suggestions or issues with this?= =C2=A0 Please consider implementing this and help make multi-directory pack= ages a reality.
--001a113d2b82681c490533e7e937--