From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#17848: #17848 add suffix search to -l even when directory part in argument Date: Tue, 06 Sep 2016 18:05:40 +0300 Message-ID: <83k2epax17.fsf@gnu.org> References: <8737lyulkl.fsf@users.sourceforge.net> <878tv9ndce.fsf@users.sourceforge.net> <831t10evoh.fsf@gnu.org> <8760qb9v5v.fsf_-_@users.sourceforge.net> <838tv6crlw.fsf@gnu.org> <8737le9cmt.fsf@users.sourceforge.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1473174579 21740 195.159.176.226 (6 Sep 2016 15:09:39 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Sep 2016 15:09:39 +0000 (UTC) Cc: 17848@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 06 17:09:32 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhI0B-0004l4-1L for geb-bug-gnu-emacs@m.gmane.org; Tue, 06 Sep 2016 17:09:31 +0200 Original-Received: from localhost ([::1]:34236 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhI08-0000Ml-Mx for geb-bug-gnu-emacs@m.gmane.org; Tue, 06 Sep 2016 11:09:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59669) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhHxs-0006wc-8E for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2016 11:07:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhHxm-0007E5-5s for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2016 11:07:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhHxm-0007E1-1h for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2016 11:07:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1bhHxl-0008NY-SO for bug-gnu-emacs@gnu.org; Tue, 06 Sep 2016 11:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 15:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17848 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 17848-submit@debbugs.gnu.org id=B17848.147317437032141 (code B ref 17848); Tue, 06 Sep 2016 15:07:01 +0000 Original-Received: (at 17848) by debbugs.gnu.org; 6 Sep 2016 15:06:10 +0000 Original-Received: from localhost ([127.0.0.1]:51443 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhHws-0008MG-NE for submit@debbugs.gnu.org; Tue, 06 Sep 2016 11:06:10 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:40222) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhHwn-0008Ld-LU for 17848@debbugs.gnu.org; Tue, 06 Sep 2016 11:06:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhHwd-0006zc-Kf for 17848@debbugs.gnu.org; Tue, 06 Sep 2016 11:05:56 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:55773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhHwd-0006zJ-HD; Tue, 06 Sep 2016 11:05:51 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4123 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bhHwb-0003iD-En; Tue, 06 Sep 2016 11:05:49 -0400 In-reply-to: <8737le9cmt.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:122997 Archived-At: > From: npostavs@users.sourceforge.net > Cc: 17848@debbugs.gnu.org, rgm@gnu.org > Date: Mon, 05 Sep 2016 18:59:22 -0400 > > > I'm not sure. Wouldn't adding the leading directory to load-path in a > > let-binding be a cleaner solution? IOW, I don't understand the reason > > for the "Take file from default dir if it exists there" logic in the > > first place -- what are we gaining there? > > If we let-bind `load-path', then this could influence the code that > we're loading. For more context, I came to this bug from > test/Makefile.in: > > ## We need to use $loadfile because: > ## i) -L :$srcdir -l basename does not work, because we have files whose > ## basename duplicates a file in lisp/ (eg eshell.el). > ## ii) Although -l basename will automatically load .el or .elc, > ## -l ./basename treats basename as a literal file (it would be nice > ## to change this; bug#17848 - if that gets done, this can be simplified). You have a point there, indeed. However, I don't think the proposed solution, to pass to 'load' the explicit absolute file name of a file that 'locate-file' found, is TRT here. Here's my rationale: Stepping back a notch, what is the root cause of the reported bug? The root cause, AFAICT, is that ./foo doesn't exist, and therefore we pass literally "./foo" to 'load', which then looks for this relative file name in every directory in load-path, and doesn't try the current directory. If we were to pass an absolute file name "/some/where/foo" to 'load', it wouldn't have looked along load-path, but instead would try /some/where/foo.elc, /some/where/foo.el, etc. -- exactly as requested. The proposed patch indeed passes an absolute file name to 'load', but it passes the name of the first candidate file found by 'locate-file', and that could very well be different from what 'load' would have found, because 'load' has some additional features and logic that 'locate-file' doesn't. So I think what we need is to see if 'locate-file' finds _any_ candidate at all, and if it does, simply pass to 'load' the result of (expand-file-name file) disregarding the file name returned by 'locate-file'; and we should do that only if 'file' is not an absolute file name to begin with. WDYT? One other thought: should we prefer an exact match, without any extensions, in this particular case? IOW, should "-l ./foo" prefer 'foo" even if "foo.el" or "foo.gz" etc. exist in the current directory? If we should indeed prefer an exact match, then we might need to tweak the order of the suffixes to support that. Thanks.