From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alex Kosorukoff Newsgroups: gmane.emacs.bugs Subject: bug#17467: 24.3; locate-library returning spurious path Date: Sun, 11 May 2014 17:20:23 -0700 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a11c1ed8a00852804f928eb3d X-Trace: ger.gmane.org 1399854084 17444 80.91.229.3 (12 May 2014 00:21:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 May 2014 00:21:24 +0000 (UTC) Cc: 17467 <17467@debbugs.gnu.org> To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 12 02:21:17 2014 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 1WjdzY-0001BW-1d for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 May 2014 02:21:16 +0200 Original-Received: from localhost ([::1]:34748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjdzX-0002va-Ic for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 20:21:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53164) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjdzP-0002vI-HI for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:21:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjdzK-0007FX-JS for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:21:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjdzK-0007FT-EQ for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:21:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjdzJ-0007hj-Vv for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:21:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Kosorukoff Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 May 2014 00:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17467 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17467-submit@debbugs.gnu.org id=B17467.139985405329589 (code B ref 17467); Mon, 12 May 2014 00:21:01 +0000 Original-Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:20:53 +0000 Original-Received: from localhost ([127.0.0.1]:59868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjdzA-0007hA-NB for submit@debbugs.gnu.org; Sun, 11 May 2014 20:20:53 -0400 Original-Received: from mail-ob0-f177.google.com ([209.85.214.177]:41189) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjdz7-0007gt-6a for 17467@debbugs.gnu.org; Sun, 11 May 2014 20:20:50 -0400 Original-Received: by mail-ob0-f177.google.com with SMTP id gq1so7066082obb.8 for <17467@debbugs.gnu.org>; Sun, 11 May 2014 17:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5n6APP+rwRdZHGZuKjqLkPKC5IO7T84hTJA1sIA2OBM=; b=l9qcQ/sKkAzEaN1EfSH849IZ5kNrr96tZa8Q9mzVkKrsA5aJBLiyMUq7Ih2BrQcay/ xGwO4VAR/aytih6W10p3KUNoQ6j3+EmrqnuMH884ez6TcN3hBl7J2kELBH1rsw80dxeH ec+eRPu15bkZ0g5O7wjvtaoM0ETb94wCi+IvfVvUR2nEwzhAo4H3FZSOFVo2y5kwrjEA jc7BLwRWQyCUQ0G1obqoNoUtfwc4Isdyk/t1nGcZkhdg1lGBc/jZDL00MSNMEgzOfhIy U1CYNiViPo/pSaAp6w3rXsMRwgcLaZs+xawNblMRSP4cq1AawfIOD5ePhibyaIhgSxVC Q/mA== X-Received: by 10.182.66.170 with SMTP id g10mr29706515obt.49.1399854043528; Sun, 11 May 2014 17:20:43 -0700 (PDT) Original-Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 17:20:23 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: KItpMBUDeGGuV-LGZZHgvnyR8s8 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:88945 Archived-At: --001a11c1ed8a00852804f928eb3d Content-Type: text/plain; charset=UTF-8 On Sun, May 11, 2014 at 2:56 PM, Stefan Monnier wrote: > > The issue is that locate-library returns spurious paths like ".*/tramp" > or > > ".*xxx/tramp.gz" > > I don't see why these are necessarily spurious. Please give very > concrete examples, so as to make it crystal clear why they're spurious. > I think these file names are more appropriate for data files, not executable ones. It is undesirable that a name "tramp.gz" will shadow a valid library file "tramp.elc" that won't be found as a result. When you say those names aren't spurious, do you have a particular example of an emacs elisp library in mind which file name ends with a suffix other than .el .elc .el.gz .elc.gz? I think the main difference is that I assume that this list is exhaustive and you imply that it is not. You can prove me wrong by a single example. > This is both unexpected and incorrect given this function name and > > spec. > > Unexpected to you, obviously, but I'm not convinced it's unexpected in > general (after all, I don't remember other bug-reports in this area) and > definitely not incorrect. See the docstring of `load': > > Execute a file of Lisp code named FILE. > First try FILE with `.elc' appended, then try with `.el', > then try FILE unmodified (the exact suffixes in the exact order are > determined by `load-suffixes'). Environment variable references in > [...] > By incorrect, I only meant that the function fails to do what its name suggests when it returns something other than a library. My understanding is that load is used to load any files, not just libraries. > Of course, there's an ambiguity about how the search is performed, > w.r.t. to whether it does: > > (dolist (s suffixes) (dolist (d load-path) ...))) > or > (dolist (d load-path) (dolist (s suffixes) ...))) > > We do the second, so that a compiled file in a later directory does not > override a non-compiled file in an earlier directory. > Yes, I noticed that require won't attempt to load files like "trump" or "trump.gz" even if they are in the load-path, unlike load that will try to load any file regardless of its suffix. My understanding was that require is used to load libraries, while load is used to load general files. > > Stefan > --001a11c1ed8a00852804f928eb3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 11, 2014 at 2:56 PM, Stefan Monnier <= monnier@iro.umontreal.ca> wrote:
> The issue is that locat= e-library returns spurious paths like ".*/tramp" or
> ".*xxx/tramp.gz"

I don't see why these are necessarily spurious. =C2=A0Please give= very
concrete examples, so as to make it crystal clear why they're spurious.=

I think these file names are mor= e appropriate for data files, not executable ones. It is undesirable that a= name "tramp.gz" will shadow a valid library file "tramp.elc= " that won't be found as a result. When you say those names aren&#= 39;t spurious, do you have a particular =C2=A0example of an emacs elisp lib= rary in mind which file name ends with a suffix other than .el .elc .el.gz = .elc.gz? I think the main difference is that I assume that this list is exh= austive and you imply that it is not. You can prove me wrong by a single ex= ample.

> This is both unexpected and incorrect given this funct= ion name and
> spec.

Unexpected to you, obviously, but I'm not convinced it's unex= pected in
general (after all, I don't remember other bug-reports in this area) an= d
definitely not incorrect. =C2=A0See the docstring of `load':

=C2=A0 =C2=A0Execute a file of Lisp code named FILE.
=C2=A0 =C2=A0First try FILE with `.elc' appended, then try with `.el= 9;,
=C2=A0 =C2=A0then try FILE unmodified (the exact suffixes in the exact orde= r are
=C2=A0 =C2=A0determined by `load-suffixes'). =C2=A0Environment variable= references in
=C2=A0 =C2=A0[...]

By incorrect, = I only meant that the function fails to do what its name suggests when it r= eturns something other than a library. My understanding is that load is use= d to load any files, not just libraries.
=C2=A0
Of course, there's an ambiguity about how the search is performed,
w.r.t. to whether it does:

=C2=A0 =C2=A0(dolist (s suffixes) (dolist (d load-path) ...)))
or
=C2=A0 =C2=A0(dolist (d load-path) (dolist (s suffixes) ...)))

We do the second, so that a compiled file in a later directory does not
override a non-compiled file in an earlier directory.
=
Yes, I noticed that require won't attempt to load = files like "trump" or "trump.gz" even if they are in th= e load-path, unlike load that will try to load any file regardless of its s= uffix. My understanding was that require is used to load libraries, while l= oad is used to load general files.

=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--001a11c1ed8a00852804f928eb3d--