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: Thu, 15 May 2014 16:57:27 -0700 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113a98d06d9d8704f9791051 X-Trace: ger.gmane.org 1400198303 13947 80.91.229.3 (15 May 2014 23:58:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 May 2014 23:58:23 +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 Fri May 16 01:58:16 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 1Wl5XT-0007CU-Sr for geb-bug-gnu-emacs@m.gmane.org; Fri, 16 May 2014 01:58:16 +0200 Original-Received: from localhost ([::1]:60985 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl5XT-0002Xq-4w for geb-bug-gnu-emacs@m.gmane.org; Thu, 15 May 2014 19:58:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32961) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl5XL-0002Xh-Qz for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 19:58:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wl5XG-00083L-VE for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 19:58:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43411) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wl5XG-00083B-RT for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 19:58:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1Wl5XG-0006Kt-34 for bug-gnu-emacs@gnu.org; Thu, 15 May 2014 19:58: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: Thu, 15 May 2014 23:58: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.140019827724341 (code B ref 17467); Thu, 15 May 2014 23:58:01 +0000 Original-Received: (at 17467) by debbugs.gnu.org; 15 May 2014 23:57:57 +0000 Original-Received: from localhost ([127.0.0.1]:36475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl5XA-0006KT-JK for submit@debbugs.gnu.org; Thu, 15 May 2014 19:57:57 -0400 Original-Received: from mail-qc0-f174.google.com ([209.85.216.174]:51959) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl5X8-0006KD-Fd for 17467@debbugs.gnu.org; Thu, 15 May 2014 19:57:55 -0400 Original-Received: by mail-qc0-f174.google.com with SMTP id x13so3099876qcv.33 for <17467@debbugs.gnu.org>; Thu, 15 May 2014 16:57:48 -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=HZsNJTp+vki3URQbmJICb3iN/ht1o9jzZOdfJudUGjE=; b=I46uX42nMGqr4cy1hlsF27aFfV06yqpjE9TMJdz0Eg7FXlB3dYJO4J6x7MnloQidEy yHHg9oLUYOKH114dF9+QaI7C1iN0CZ4I10zAZtJlfuSd2uA7kPcUYaULDaP8jamyFvEH zq8lRpVfunAji081Ybz3KPkyuZr1MFM3jvcPoX0jQVZ8E5p8H5nfFPlHjN3LJ5Sci4+g HWwjD+2S0wTGMCDeiuL4yam6oByG1/AR942q/dMpAFuyPBQjGLZecc+SXB8HsWgORcaC 6rILs5TST3mMwv/ENn6t3vUOsk0D5Ts6uVY0XeRDgXri36ol+a95iMkPGg6GUBGOOPZi fH7w== X-Received: by 10.140.94.39 with SMTP id f36mr19667774qge.64.1400198268818; Thu, 15 May 2014 16:57:48 -0700 (PDT) Original-Received: by 10.140.96.195 with HTTP; Thu, 15 May 2014 16:57:27 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: vOctSakizhfvn690s1nDWJzSin0 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:89142 Archived-At: --001a113a98d06d9d8704f9791051 Content-Type: text/plain; charset=UTF-8 On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier wrote: > > locate-library incorrectly generates a set of suffixes to extend the > > base library name (".elc" ".elc.gz" ".el" ".el.gz" "" ".gz"), while it > > should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is > > nil. > > FWIW, this simply reflects what `load' does, so changing it in > `locate-library' would mean that it doesn't do what `load' does, which > I would count as a bug. > I agree with you that locate library should do what load does. > The main issue I see is that `load' includes a `must-suffix' argument > which provides the behavior you're looking for (and which is used by > `require') whereas locate-library doesn't provide it. > > > This leads to spurious paths found, like name.gz. I found > > this issue because (locate-library "tramp") was returning > > "/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc". The workaround > > is (locate-file "tramp" load-path (get-load-suffixes)) > > IIUC the problem you had was with `load' rather than with > `locate-library', so I think what this boils down to is that the `load' > that looks for `trump' should be changed to provide `must-suffix'. > WDYT? > In fact, I was looking for a function that would locate library and return the path to it, so I could compile the explicit path into .elc file that will avoid searching load-path and save time when it is run. locate-library seems like a perfect tool for this purpose, but turned out to be not as useful as it sounds because it is not currently capable of correctly reproducing search behavior of load or require. As a result, I switched to locate-file. This currently seems to be the only reliable way to find correct paths to libraries. I think we could make locate-library more useful by extending it in one of two possible ways. It can either accept symbol argument as well as string and behave exactly like require does in this case (currently it will just fail with error if given a symbol). An alternative way is to add an optional must-suffix argument to make it consistent with load. Both ways will keep it backward compatible and will allow it to emulate the logic of both load and require. > > > Stefan > --001a113a98d06d9d8704f9791051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier <= monnier@iro.umontreal.ca> wrote:
> locate-library incorrec= tly generates a set of suffixes to extend the
> base library name (".elc" ".elc.gz" ".e= l" ".el.gz" "" ".gz"), while it
> should be just (".elc" ".elc.gz" &= quot;.el" ".el.gz") when nosuffix is
> nil.

FWIW, this simply reflects what `load' does, so changing it in `locate-library' would mean that it doesn't do what `load' does= , which
I would count as a bug.

I agree w= ith you that locate library should do what load does.
=C2=A0
The main issue I see is that `load' includes a `must-suffix' argume= nt
which provides the behavior you're looking for (and which is used by `require') whereas locate-library doesn't provide it.

> This leads to spurious paths found, like name.gz. I found
> this issue because (locate-library "tramp") = was returning
> "/home/alex/.emacs.d/trump" not "= ../lisp/net/trum.elc". The workaround
> is (locate-file "tramp" load-path (get-load-suffixes))

IIUC the problem you had was with `load' rather than with
`locate-library', so I think what this boils down to is that the `load&= #39;
that looks for `trump' should be changed to provide `must-suffix'.<= br> WDYT?

In fact, I was looking for = a function that would locate library and return the path to it, so I could = compile the explicit path into .elc file that will avoid searching load-pat= h and save time when it is run. locate-library seems like a perfect tool fo= r this purpose, but turned out to be not as useful as it sounds because it = is not currently capable of correctly reproducing search behavior of load o= r require. As a result, I switched to locate-file. This currently seems to = be the only reliable way to find correct paths to libraries. I think we cou= ld make locate-library more useful by extending it in one of two possible w= ays. It can either accept symbol argument as well as string and behave exac= tly like require does in this case (currently it will just fail with error = if given a symbol). An alternative way is to add an optional must-suffix ar= gument to make it consistent with load. Both ways will keep it backward com= patible and will allow it to emulate the logic of both load and require.
=C2=A0


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

--001a113a98d06d9d8704f9791051--