GNU bug report logs - #17467
24.3; locate-library returning spurious path

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Severity: minor; Reported by: Alex Kosorukoff <alex@HIDDEN>; dated Sun, 11 May 2014 16:51:02 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 15 May 2014 23:57:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 15 19:57:57 2014
Received: from localhost ([127.0.0.1]:36475 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wl5XA-0006KT-JK
	for submit <at> debbugs.gnu.org; Thu, 15 May 2014 19:57:57 -0400
Received: from mail-qc0-f174.google.com ([209.85.216.174]:51959)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1Wl5X8-0006KD-Fd
 for 17467 <at> debbugs.gnu.org; Thu, 15 May 2014 19:57:55 -0400
Received: by mail-qc0-f174.google.com with SMTP id x13so3099876qcv.33
 for <17467 <at> 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)
MIME-Version: 1.0
Received: by 10.140.96.195 with HTTP; Thu, 15 May 2014 16:57:27 -0700 (PDT)
In-Reply-To: <jwvha4qltsr.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4qltsr.fsf-monnier+emacsbugs@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Thu, 15 May 2014 16:57:27 -0700
X-Google-Sender-Auth: vOctSakizhfvn690s1nDWJzSin0
Message-ID: <CAHD9_tRUbrJ_U2Cgt=3u-1RSXPiEzrhvJVWJH-t7fayY3reCTQ@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=001a113a98d06d9d8704f9791051
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a113a98d06d9d8704f9791051
Content-Type: text/plain; charset=UTF-8

On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier
<monnier@HIDDEN>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

<div dir=3D"ltr">On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier <span dir=
=3D"ltr">&lt;<a href=3D"mailto:monnier@HIDDEN" target=3D"_blank">=
monnier@HIDDEN</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">&gt; locate-library incorrec=
tly generates a set of suffixes to extend the<br>
</div>&gt; base library name (&quot;.elc&quot; &quot;.elc.gz&quot; &quot;.e=
l&quot; &quot;.el.gz&quot; &quot;&quot; &quot;.gz&quot;), while it<br>
<div class=3D"">&gt; should be just (&quot;.elc&quot; &quot;.elc.gz&quot; &=
quot;.el&quot; &quot;.el.gz&quot;) when nosuffix is<br>
&gt; nil.<br>
<br>
</div>FWIW, this simply reflects what `load&#39; does, so changing it in<br=
>
`locate-library&#39; would mean that it doesn&#39;t do what `load&#39; does=
, which<br>
I would count as a bug.<br></blockquote><div><br></div><div style>I agree w=
ith you that locate library should do what load does.</div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">

The main issue I see is that `load&#39; includes a `must-suffix&#39; argume=
nt<br>
which provides the behavior you&#39;re looking for (and which is used by<br=
>
`require&#39;) whereas locate-library doesn&#39;t provide it.<br>
<br>
&gt; This leads to spurious paths found, like name.gz. I found<br>
<div class=3D"">&gt; this issue because (locate-library &quot;tramp&quot;) =
was returning<br>
</div><div class=3D"">&gt; &quot;/home/alex/.emacs.d/trump&quot; not &quot;=
../lisp/net/trum.elc&quot;. The workaround<br>
&gt; is (locate-file &quot;tramp&quot; load-path (get-load-suffixes))<br>
<br>
</div>IIUC the problem you had was with `load&#39; rather than with<br>
`locate-library&#39;, so I think what this boils down to is that the `load&=
#39;<br>
that looks for `trump&#39; should be changed to provide `must-suffix&#39;.<=
br>
WDYT?<br></blockquote><div><br></div><div style>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.</d=
iv>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan<br>
</font></span></blockquote></div><br></div></div>

--001a113a98d06d9d8704f9791051--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 15 May 2014 19:40:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu May 15 15:40:49 2014
Received: from localhost ([127.0.0.1]:36375 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wl1WK-0006QV-1X
	for submit <at> debbugs.gnu.org; Thu, 15 May 2014 15:40:48 -0400
Received: from mercure.iro.umontreal.ca ([132.204.24.67]:35592)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1Wl1WH-0006QK-Li
 for 17467 <at> debbugs.gnu.org; Thu, 15 May 2014 15:40:46 -0400
Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca
 [132.204.27.50])
 by mercure.iro.umontreal.ca (Postfix) with ESMTP id 18E7484E0E;
 Thu, 15 May 2014 15:40:41 -0400 (EDT)
Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca
 [132.204.27.242])
 by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 811BF1E5BD3;
 Thu, 15 May 2014 15:39:00 -0400 (EDT)
Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848)
 id 66AB7B40F9; Thu, 15 May 2014 15:39:00 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
Message-ID: <jwvha4qltsr.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
Date: Thu, 15 May 2014 15:39:00 -0400
In-Reply-To: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 09:06:10 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-DIRO-MailScanner-Information: Please contact the ISP for more information
X-DIRO-MailScanner: Found to be clean
X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel,
 SpamAssassin (score=-2.82, requis 5, autolearn=not spam,
 ALL_TRUSTED -2.82, MC_TSTLAST 0.00)
X-DIRO-MailScanner-From: monnier@HIDDEN
X-Spam-Status: No
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.0 (---)

> 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.

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?


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 17:46:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 12 13:46:42 2014
Received: from localhost ([127.0.0.1]:60994 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjuJF-0003iw-Ib
	for submit <at> debbugs.gnu.org; Mon, 12 May 2014 13:46:42 -0400
Received: from mail-qg0-f50.google.com ([209.85.192.50]:53221)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjuJC-0003ii-LK
 for 17467 <at> debbugs.gnu.org; Mon, 12 May 2014 13:46:39 -0400
Received: by mail-qg0-f50.google.com with SMTP id z60so7947205qgd.37
 for <17467 <at> debbugs.gnu.org>; Mon, 12 May 2014 10:46:33 -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=hAU3K7/li8dbV04LvBSuuuLAcF/A8dN58mla0E6Mi9U=;
 b=ZbGABwP8DnPANCo/0LVrgt5QffKleuzHX0LaHxj6J2ZXM+BbXxbWQwBZRCNovp4ZK2
 oBYQ9gsYinUCbi7HwmKmdR4ZveGraT+BZpC6U/r2FqnDTdmZRZfyAJH+30utGgMZYuEW
 LWatJJ6MCSeoHvYL5cfEfn6FW83sE/PJHuWbnC+/9KoHtD05ncj20xeJy+8pQBSH7ZmA
 Axe/BP5b5p9Af8/J8eSj3f2KHJUrSVmbAuTz548ng9tqdJJkwuU0KbrCS2dtOVME/5DF
 vXyIN7GCtYZVv+z5pftPQOBP3T+cDqFJnzVks14VZj5RKaKzbzuTrY+htHgNsIJCUsXi
 oCYw==
X-Received: by 10.140.94.39 with SMTP id f36mr38699352qge.64.1399916792927;
 Mon, 12 May 2014 10:46:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.96.195 with HTTP; Mon, 12 May 2014 10:46:12 -0700 (PDT)
In-Reply-To: <jwvd2fj33ol.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
 <jwv4n0v4ut9.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRCCswTqNUGr8F2OB1w3OUkSJanDfDiN=1xTee4exhP7w@HIDDEN>
 <jwvd2fj33ol.fsf-monnier+emacsbugs@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Mon, 12 May 2014 10:46:12 -0700
X-Google-Sender-Auth: lY5Ootp5ibv35FR3UzbMlZMT2BA
Message-ID: <CAHD9_tQWEL6kR0KF9ZRhE7FG8eyhSF0rtqcFYvku5_0LFFyKGA@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=001a113a98d0285cda04f93787bf
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)

--001a113a98d0285cda04f93787bf
Content-Type: text/plain; charset=UTF-8

On Sun, May 11, 2014 at 11:39 PM, Stefan Monnier
<monnier@HIDDEN>wrote:

> > variant matched tramp.el.old which is not a valid library name.
>
> Who cares?  The point is that if the user asks to load foo.el.old, we
> should consider load-file-rep-suffixes, whereas for "foo" we shouldn't.
> I'm not particularly worried about finding files with name "foo.el.old.el".


Do you mean we need this shortcut due to some performance considerations? I
am not sure why else we would want a partial solution when we can have a
complete one. In my opinion we should only consider load-file-rep-suffixes
if the name matches \\.elc?\\' (the difference is the end of string
marker), so foo.el and foo.el.old.el are both ok to extend with .gz, but
foo.el.old and foo shouldn't be extended. Am I missing something?

> +          (unless nosuffix
> > +            (if (string-match "\\.elc?\\(\\.gz\\)?\\'" library)
>
> I don't want to hardcode "gz" here.  We have load-file-rep-suffixes for
> that.
>

Yes, you are right, .gz shouldn't be hardcoded. Though I am not sure if
allowing anything there is ok. Maybe we can just use (sring-match (concat
"\\.elc?\\(" (regexp_opt load-file-rep-suffixes) "\\)\\'") library)?


>
> > +                (if (= 2 (length (match-data))) load-file-rep-suffixes)
> > +              (get-load-suffixes))))))
>
> If you only use (get-load-suffixes) that will fail when we (load
> "~/.gnus").
> My check for absolute-file-name-p was not an optimization.
>

Got it.

        Stefan
>

--001a113a98d0285cda04f93787bf
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, May 11, 2014 at 11:39 PM, Stefan Monnier <span dir=
=3D"ltr">&lt;<a href=3D"mailto:monnier@HIDDEN" target=3D"_blank">=
monnier@HIDDEN</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"">&gt; variant matched tramp.el.old which is=
 not a valid library name.<br>


<br>
</div>Who cares? =C2=A0The point is that if the user asks to load foo.el.ol=
d, we<br>
should consider load-file-rep-suffixes, whereas for &quot;foo&quot; we shou=
ldn&#39;t.<br>
I&#39;m not particularly worried about finding files with name &quot;foo.el=
.old.el&quot;.</blockquote><div>=C2=A0</div><div style>Do you mean we need =
this shortcut due to some performance considerations? I am not sure why els=
e we would want a partial solution when we can have a complete one. In my o=
pinion we should only consider load-file-rep-suffixes if the name matches \=
\.elc?\\&#39; (the difference is the end of string marker), so foo.el and f=
oo.el.old.el are both ok to extend with .gz, but foo.el.old and foo shouldn=
&#39;t be extended. Am I missing something?</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div class=3D"">
&gt; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(unless nosuffix<br>
&gt; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (string-match &quot;\\.=
elc?\\(\\.gz\\)?\\&#39;&quot; library)<br>
<br>
</div>I don&#39;t want to hardcode &quot;gz&quot; here. =C2=A0We have load-=
file-rep-suffixes for that.<br></blockquote><div><br></div><div style>Yes, =
you are right, .gz shouldn&#39;t be hardcoded. Though I am not sure if allo=
wing anything there is ok. Maybe we can just use (sring-match (concat &quot=
;\\.elc?\\(&quot; (regexp_opt load-file-rep-suffixes) &quot;\\)\\&#39;&quot=
;) library)?=C2=A0</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<div class=3D""><br>
&gt; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (=3D 2 (l=
ength (match-data))) load-file-rep-suffixes)<br>
&gt; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(get-load-suffixes))=
))))<br>
<br>
</div>If you only use (get-load-suffixes) that will fail when we (load &quo=
t;~/.gnus&quot;).<br>
My check for absolute-file-name-p was not an optimization.<br></blockquote>=
<div><br></div><div style>Got it.</div><div style><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;=
border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex=
">

<span class=3D""><font color=3D"#888888">=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan=
<br>
</font></span></blockquote></div><br></div></div>

--001a113a98d0285cda04f93787bf--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 06:39:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 12 02:39:14 2014
Received: from localhost ([127.0.0.1]:60092 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjjtJ-0005FX-S4
	for submit <at> debbugs.gnu.org; Mon, 12 May 2014 02:39:14 -0400
Received: from chene.dit.umontreal.ca ([132.204.246.20]:36107)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WjjtG-0005F1-1Q
 for 17467 <at> debbugs.gnu.org; Mon, 12 May 2014 02:39:10 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4C6d4vV019749;
 Mon, 12 May 2014 02:39:05 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 3D8A1600EC; Mon, 12 May 2014 02:39:04 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
Message-ID: <jwvd2fj33ol.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
 <jwv4n0v4ut9.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRCCswTqNUGr8F2OB1w3OUkSJanDfDiN=1xTee4exhP7w@HIDDEN>
Date: Mon, 12 May 2014 02:39:04 -0400
In-Reply-To: <CAHD9_tRCCswTqNUGr8F2OB1w3OUkSJanDfDiN=1xTee4exhP7w@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 21:36:22 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV4939=0
X-NAI-Spam-Version: 2.3.0.9378 : core <4939> : inlines <853> : streams
 <1180231> : uri <1754527>
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

> variant matched tramp.el.old which is not a valid library name.

Who cares?  The point is that if the user asks to load foo.el.old, we
should consider load-file-rep-suffixes, whereas for "foo" we shouldn't.
I'm not particularly worried about finding files with name "foo.el.old.el".

> +          (unless nosuffix
> +            (if (string-match "\\.elc?\\(\\.gz\\)?\\'" library)

I don't want to hardcode "gz" here.  We have load-file-rep-suffixes for that.

> +                (if (= 2 (length (match-data))) load-file-rep-suffixes)
> +              (get-load-suffixes))))))

If you only use (get-load-suffixes) that will fail when we (load "~/.gnus").
My check for absolute-file-name-p was not an optimization.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 04:36:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon May 12 00:36:52 2014
Received: from localhost ([127.0.0.1]:59988 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wjhyt-0008Mu-3z
	for submit <at> debbugs.gnu.org; Mon, 12 May 2014 00:36:52 -0400
Received: from mail-qa0-f51.google.com ([209.85.216.51]:37500)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1Wjhyp-0008Ma-Vs
 for 17467 <at> debbugs.gnu.org; Mon, 12 May 2014 00:36:49 -0400
Received: by mail-qa0-f51.google.com with SMTP id w8so6451875qac.38
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 21:36:42 -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=sycVzAnmtb+qnLQ09v2yogGLrF0L7fgOkpl2bTQIXKY=;
 b=erANLM6p1EWBwHjUzb/dl/xJYR9CiFuixD/onGcZGcj8sd7ks3rfSN1Kt57lC8kkmu
 uMHAdlXX5rLWPbuHPk6TqDugvA3hQNm8KQj5TSnmZw/jW3X0chDWrDFcGjVV858I8DDT
 2bC7wVwS+sGIjPGG3TDLcluPA8F32xITRWiaY7aluWGw9sYDQt7K8mrh+vXmw8Cd9+X7
 UF7n/cKz39C4lzMJr/O9XP7RzpkBL9EfSpGB5n5VKU9HcGtDJ/VuLicQ5cXHwz6VB6HC
 L9a6F46S5z4yAImxFFabOPvoWY+7tYLElPZTacWMYZT+XU31LmOmOwa7G3YMF8Sd0D2E
 hXGw==
X-Received: by 10.229.236.1 with SMTP id ki1mr34759492qcb.8.1399869402271;
 Sun, 11 May 2014 21:36:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.96.195 with HTTP; Sun, 11 May 2014 21:36:22 -0700 (PDT)
In-Reply-To: <jwv4n0v4ut9.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
 <jwv4n0v4ut9.fsf-monnier+emacsbugs@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 21:36:22 -0700
X-Google-Sender-Auth: apUIXmfzmeAbLO26mf2VK109Vk8
Message-ID: <CAHD9_tRCCswTqNUGr8F2OB1w3OUkSJanDfDiN=1xTee4exhP7w@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=001a1134bdda74595a04f92c7ec7
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.4 (/)

--001a1134bdda74595a04f92c7ec7
Content-Type: text/plain; charset=UTF-8

I like the idea of optimizing out the second string-match, though that
variant matched tramp.el.old which is not a valid library name. Here is a
modifed version using the same idea except it skips files like tramp.el.old.

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: alex@HIDDEN
# target_branch: :parent
# testament_sha1: 330ab5b4527e49ea46d8d16a6d47e5822247ce77
# timestamp: 2014-05-11 21:23:50 -0700
# base_revision_id: monnier@HIDDEN\
#   1mzcrftziwhrw9hl
#
# Begin patch
=== modified file 'lisp/subr.el'
--- lisp/subr.el        2014-04-09 01:48:07 +0000
+++ lisp/subr.el        2014-05-12 04:22:18 +0000
@@ -1857,10 +1857,14 @@
                                        load-path (get-load-suffixes)))
                     nil nil
                     t))
-  (let ((file (locate-file library
-                          (or path load-path)
-                          (append (unless nosuffix (get-load-suffixes))
-                                  load-file-rep-suffixes))))
+  (let ((file
+         (locate-file
+          library
+          (or path load-path)
+          (unless nosuffix
+            (if (string-match "\\.elc?\\(\\.gz\\)?\\'" library)
+                (if (= 2 (length (match-data))) load-file-rep-suffixes)
+              (get-load-suffixes))))))
     (if interactive-call
        (if file
            (message "Library is file %s" (abbreviate-file-name file))

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWdDpudEABgd/gDN0FUFQ4//3
8wgABL////BgCI+FAA0AAAAAAAAMkk2p6mmgBoDQaADTQAABoGlQZPSMmynpqDJo0AaZADTIyABz
CYBMAJhMJpgAAEyaaBjmEwCYATCYTTAAAJk00DHMJgEwAmEwmmAAATJpoGCpRAJoATEDRDQCYJT1
NNqY1NkylAzQWMD1e2laABxxxTQHTYJXxEfUiG4Q6b22N1Uag1frP3pbf2aB7XuzlcK84k5F8VNn
K7C8uNBohJUOdK//P1n8bZy3bNmOF6+X2+h/c3FChQf7/zDTaaSkcqN+uu/7XlheXcb+7RLjabTu
P27z/NnCO/mwLDn/FKKlFBiUHHTs3fk/3T+uRYAsB4BdK8urI8LfFgkLYyS2WyCO5UQmtUUEMWlG
zCpPr9qvxRVZXznh5+Va2K/lUqoc7pu4dvX+RkjytniPmaD/hD4GJ5o2+573zPmWFJ/EuPsT5sF7
mXta2bUb099NVld5uEfL5kp0ltH3PA47Nta1rWta1+Px8PlTbiJYcq/XF1wJvdameWVgilnVjdWk
xvQv+zpoWXSQuRejL+HbVarMLMpf26a1ywJSizNrtJZC9haxswi4/Wmd6OCO9G+wsVHDcVhaWztM
teiJdp29o3eo03xKEoRxYpFxebbktJwu36bqr+zRhdy4bDkjST9kyybzSIsJara5G044Zf3G7Zwf
rwTPYjoTrna5aCap2U6SZDiYMOiNqNrDdxpZZz4Z8+2YtFV/bmf8WdlHKytPxSy4msoI0prJRJhc
m7v5JxU8GCzQ0GGWom/Cps09tsEupZqmGlKuiquk7JkArLJwBSQA4Yjggswlu0AkkXDE0r6pv4WT
NbwXqs+xr7MNSxGqmxhJqL64VoyLuN91Nd+ei223D9hFiPYm5GzDDKUpLK8M9QjffUmGmmBLkzrf
Teowa7yU3XWYyOXibKFKFGNqK3NEpa30HEZNbNgs3adVJnkuRozdqNRu0YeNX6IsGAizX10tm062
79MxxRqpvW5o32KotcDbqb11VlyODLRe1f2K2NTJotYfyT0JWXreaOGSzTfZOK9WyxoZ25Uo3b54
W4drBjaorX+kyXcGtqDsNFpQacOWlru+SPl62/bMmubsquHfsus02LF3ZfoqXNFYbjFJ5Iu0sW3D
JUlLM0USi9Rwkb7tSjxpuNunLnlfYjORmX18fCsi/GccJvbjQzWGPA219SK604WzHpdymktuJ2rt
3DabbSZ6GmLmdIXZs4t2zTbZjOtd/DJdjctlDeLWWu9sxuUWYV1vdPij3W5YFZNsm7EKlk1lLDMp
eXlSWlSULylowiX4FDcdD/senkaPEo+PhSlKUpWhYUPE/Y4HL7UfQR5nka00UpIpQp/FbDafVH7v
SlNcrw3nAyg/HvsHSm47lLO24PV39/2S71+7Q8dczcOrDyVvyR9/nJluXcDxiWnqdqnhFFVKxRVS
sUVUr+57e47jE2I+WwiyRYj0jXQ2JcVPjg5O5h320596L/cv73bXVdYlGhRlOa7u8ZPzJ0Ocj6E+
qPeHBzer5Y6eV99k8rrNS6RvYbqccMPyn0OU9ibOeezo1XPzRXPDn0Ydvmeo7+yhuEcD2zC6TLc7
vaadm+vVGor0ncou2w8MdBNbmuNBM+/LplXbXKdGC2i7fLtvknrGtGo77yZ+MnclEya8eKvGmv64
XfYorZcurZXPLLuPQtuk0lKmBnEw0Ph7i9su2Mu967yUy8ftNzAnTuNvHG7Tcfc09T1pL8d2V55P
Syw9ffws/YoM5vRu5j4Eokx8fA8jt8z8CwpkeYp5zQFSRiS0/NgdCs9NnnPHt9S73188uMxY4PB4
+BLbu7TjqW4W+NmyaRr1EsehjuHwkn1+H0KT5H4NMk920RZHQ8JQtjinJHwg0zsu8Uek5TrFI9lP
YGnrPfOBOpic0U7uGqRTWcz+iUKl5vOwdILBz+MTXojDuN5acA/Q+AbT2nSaz+SkjAu0p7E3IwTq
jvjicomB3yO6J1KQaQ0lZDzifR1qV6ZlP5MhHuR/54+RSPwXeB6z+bpfNCptPYQ4iN6KlYvl9TQe
ZvHUwLDSXFR7ZfcGkuLIlhRM8zgZC4wOwl5FhhUlCddRkTZEr7D8vAkYB1N4vjge2J4GmCfWwn9H
E3bWBufVGk49ChQlF6wYGfK80E5ouUo9CZp7EULIlkk2FxGbE8DUOUy9mMfNM4idCy3aXl1p7JqW
FIUFpxKF1SsajXSlFKUpkaAoXz20lKSlJTEtMCXxOkeo/sULzRN0oUv1Ixp2FZciwsPuK7CiKmsx
HmeVwz6mkZRNAUilSypNp1nqJeThSSfRFp9DE7C72IvT7kzJ2BtjGUjVPX5E1k0WmBRKCKQoTCSL
kfojNHrRqRn90b6uz0mmNfbO9Nh/+LuSKcKEhodNzog=



On Sun, May 11, 2014 at 7:18 PM, Stefan Monnier <monnier@HIDDEN>wrote:

> > 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.
>
> I think I'm beginning to see what you mean.  So far we have simply
> considered "if it hurts, don't do it".  And it worked well enough.
>
> > 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?
>
> There are a few (~/.emacs being the most obvious), but admittedly,
> I think they all share the property of not being searched for in
> load-path.  So we could probably strengthen the search along the lines
> you suggest without (hopefully) breaking existing code with a hack along
> the lines of the one below.
>
>
>         Stefan
>
>
> === modified file 'lisp/subr.el'
> --- lisp/subr.el        2014-04-15 17:03:15 +0000
> +++ lisp/subr.el        2014-05-12 02:15:04 +0000
> @@ -1878,10 +1878,15 @@
>                                         load-path (get-load-suffixes)))
>                      nil nil
>                      t))
> -  (let ((file (locate-file library
> -                          (or path load-path)
> -                          (append (unless nosuffix (get-load-suffixes))
> -                                  load-file-rep-suffixes))))
> +  (let* ((suffixes
> +          (nconc (unless nosuffix (get-load-suffixes))
> +                 (when (or (file-name-absolute-p library)
> +                           ;; (load "foo.el") should find /bar/foo.el.gz,
> +                           ;; but (load "foo") should not find
> /bar/foo.gz.
> +                           (string-match "\\.el\\(\\.[[:alnum:]]+\\)?"
> +                                         library))
> +                   load-file-rep-suffixes)))
> +         (file (locate-file library (or path load-path) suffixes)))
>      (if interactive-call
>         (if file
>             (message "Library is file %s" (abbreviate-file-name file))
>
>

--001a1134bdda74595a04f92c7ec7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I like the idea of optimizing out the second string-match,=
 though that variant matched tramp.el.old which is not a valid library name=
. Here is a modifed version using the same idea except it skips files like =
tramp.el.old.<div>

<br></div><div><div># Bazaar merge directive format 2 (Bazaar 0.90)</div><d=
iv># revision_id: alex@HIDDEN</div><div>=
# target_branch: :parent</div><div># testament_sha1: 330ab5b4527e49ea46d8d1=
6a6d47e5822247ce77</div>

<div># timestamp: 2014-05-11 21:23:50 -0700</div><div># base_revision_id: m=
onnier@HIDDEN\</div><div># =C2=A0 1mzcrftziwhrw9h=
l</div><div>#=C2=A0</div><div># Begin patch</div><div>=3D=3D=3D modified fi=
le &#39;lisp/subr.el&#39;</div>

<div>--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-04-09 01:48:07 +0000<=
/div><div>+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-12 04:22:18 +=
0000</div><div>@@ -1857,10 +1857,14 @@</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 load-path (get-load-suffixes)))</=
div>

<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0nil nil</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0t))</div><div>- =C2=A0(let ((file (locate-file l=
ibrary</div><div>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or path load-path)</div><div>- =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(append (unless nosuffix (get-load-suffixes))</div>

<div>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load-file-rep-suffixes)=
)))</div><div>+ =C2=A0(let ((file</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (=
locate-file</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0library</div><div=
>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or path load-path)</div><div>+ =C2=A0=
 =C2=A0 =C2=A0 =C2=A0 =C2=A0(unless nosuffix</div>

<div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (string-match &quot;\\.=
elc?\\(\\.gz\\)?\\&#39;&quot; library)</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (=3D 2 (length (match-data))) load-file-=
rep-suffixes)</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(=
get-load-suffixes))))))</div>

<div>=C2=A0 =C2=A0 =C2=A0(if interactive-call</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 (if file</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (me=
ssage &quot;Library is file %s&quot; (abbreviate-file-name file))</div><div=
><br></div><div># Begin bundle</div><div>IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIH=
Y0CiMKQlpoOTFBWSZTWdDpudEABgd/gDN0FUFQ4//3</div>

<div>8wgABL////BgCI+FAA0AAAAAAAAMkk2p6mmgBoDQaADTQAABoGlQZPSMmynpqDJo0AaZAD=
TIyABz</div><div>CYBMAJhMJpgAAEyaaBjmEwCYATCYTTAAAJk00DHMJgEwAmEwmmAAATJpoG=
CpRAJoATEDRDQCYJT1</div><div>NNqY1NkylAzQWMD1e2laABxxxTQHTYJXxEfUiG4Q6b22N1=
Uag1frP3pbf2aB7XuzlcK84k5F8VNn</div>

<div>K7C8uNBohJUOdK//P1n8bZy3bNmOF6+X2+h/c3FChQf7/zDTaaSkcqN+uu/7XlheXcb+7R=
LjabTu</div><div>P27z/NnCO/mwLDn/FKKlFBiUHHTs3fk/3T+uRYAsB4BdK8urI8LfFgkLYy=
S2WyCO5UQmtUUEMWlG</div><div>zCpPr9qvxRVZXznh5+Va2K/lUqoc7pu4dvX+RkjytniPma=
D/hD4GJ5o2+573zPmWFJ/EuPsT5sF7</div>

<div>mXta2bUb099NVld5uEfL5kp0ltH3PA47Nta1rWta1+Px8PlTbiJYcq/XF1wJvdameWVgil=
nVjdWk</div><div>xvQv+zpoWXSQuRejL+HbVarMLMpf26a1ywJSizNrtJZC9haxswi4/Wmd6O=
CO9G+wsVHDcVhaWztM</div><div>teiJdp29o3eo03xKEoRxYpFxebbktJwu36bqr+zRhdy4bD=
kjST9kyybzSIsJara5G044Zf3G7Zwf</div>

<div>rwTPYjoTrna5aCap2U6SZDiYMOiNqNrDdxpZZz4Z8+2YtFV/bmf8WdlHKytPxSy4msoI0p=
rJRJhc</div><div>m7v5JxU8GCzQ0GGWom/Cps09tsEupZqmGlKuiquk7JkArLJwBSQA4Yjggs=
wlu0AkkXDE0r6pv4WT</div><div>NbwXqs+xr7MNSxGqmxhJqL64VoyLuN91Nd+ei223D9hFiP=
Ym5GzDDKUpLK8M9QjffUmGmmBLkzrf</div>

<div>Teowa7yU3XWYyOXibKFKFGNqK3NEpa30HEZNbNgs3adVJnkuRozdqNRu0YeNX6IsGAizX1=
0tm062</div><div>79MxxRqpvW5o32KotcDbqb11VlyODLRe1f2K2NTJotYfyT0JWXreaOGSzT=
fZOK9WyxoZ25Uo3b54</div><div>W4drBjaorX+kyXcGtqDsNFpQacOWlru+SPl62/bMmubsqu=
Hfsus02LF3ZfoqXNFYbjFJ5Iu0sW3D</div>

<div>JUlLM0USi9Rwkb7tSjxpuNunLnlfYjORmX18fCsi/GccJvbjQzWGPA219SK604WzHpdymk=
tuJ2rt</div><div>3DabbSZ6GmLmdIXZs4t2zTbZjOtd/DJdjctlDeLWWu9sxuUWYV1vdPij3W=
5YFZNsm7EKlk1lLDMp</div><div>eXlSWlSULylowiX4FDcdD/senkaPEo+PhSlKUpWhYUPE/Y=
4HL7UfQR5nka00UpIpQp/FbDafVH7v</div>

<div>SlNcrw3nAyg/HvsHSm47lLO24PV39/2S71+7Q8dczcOrDyVvyR9/nJluXcDxiWnqdqnhFF=
VKxRVS</div><div>sUVUr+57e47jE2I+WwiyRYj0jXQ2JcVPjg5O5h320596L/cv73bXVdYlGh=
RlOa7u8ZPzJ0Ocj6E+</div><div>qPeHBzer5Y6eV99k8rrNS6RvYbqccMPyn0OU9ibOeezo1X=
PzRXPDn0Ydvmeo7+yhuEcD2zC6TLc7</div>

<div>vaadm+vVGor0ncou2w8MdBNbmuNBM+/LplXbXKdGC2i7fLtvknrGtGo77yZ+MnclEya8eK=
vGmv64</div><div>XfYorZcurZXPLLuPQtuk0lKmBnEw0Ph7i9su2Mu967yUy8ftNzAnTuNvHG=
7Tcfc09T1pL8d2V55P</div></div><div><div>Syw9ffws/YoM5vRu5j4Eokx8fA8jt8z8Cwp=
keYp5zQFSRiS0/NgdCs9NnnPHt9S73188uMxY4PB4</div>

<div>+BLbu7TjqW4W+NmyaRr1EsehjuHwkn1+H0KT5H4NMk920RZHQ8JQtjinJHwg0zsu8Uek5T=
rFI9lP</div><div>YGnrPfOBOpic0U7uGqRTWcz+iUKl5vOwdILBz+MTXojDuN5acA/Q+AbT2n=
Saz+SkjAu0p7E3IwTq</div><div>jvjicomB3yO6J1KQaQ0lZDzifR1qV6ZlP5MhHuR/54+RSP=
wXeB6z+bpfNCptPYQ4iN6KlYvl9TQe</div>

<div>ZvHUwLDSXFR7ZfcGkuLIlhRM8zgZC4wOwl5FhhUlCddRkTZEr7D8vAkYB1N4vjge2J4GmC=
fWwn9H</div><div>E3bWBufVGk49ChQlF6wYGfK80E5ouUo9CZp7EULIlkk2FxGbE8DUOUy9mM=
fNM4idCy3aXl1p7JqW</div><div>FIUFpxKF1SsajXSlFKUpkaAoXz20lKSlJTEtMCXxOkeo/s=
ULzRN0oUv1Ixp2FZciwsPuK7CiKmsx</div>

<div>HmeVwz6mkZRNAUilSypNp1nqJeThSSfRFp9DE7C72IvT7kzJ2BtjGUjVPX5E1k0WmBRKCK=
QoTCSL</div><div>kfojNHrRqRn90b6uz0mmNfbO9Nh/+LuSKcKEhodNzog=3D</div></div>=
<div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">

On Sun, May 11, 2014 at 7:18 PM, Stefan Monnier <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:monnier@HIDDEN" target=3D"_blank">monnier@HIDDEN=
eal.ca</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=3D"">&gt; I think these file names are more appropriate for data=
 files, not<br>
&gt; executable ones. =C2=A0It is undesirable that a name &quot;tramp.gz&qu=
ot; will shadow a<br>
&gt; valid library file &quot;tramp.elc&quot; that won&#39;t be found as a =
result.<br>
<br>
</div>I think I&#39;m beginning to see what you mean. =C2=A0So far we have =
simply<br>
considered &quot;if it hurts, don&#39;t do it&quot;. =C2=A0And it worked we=
ll enough.<br>
<div class=3D""><br>
&gt; When you say those names aren&#39;t spurious, do you have a particular=
<br>
&gt; example of an emacs elisp library in mind which file name ends with<br=
>
&gt; a suffix other than .el .elc .el.gz .elc.gz?<br>
<br>
</div>There are a few (~/.emacs being the most obvious), but admittedly,<br=
>
I think they all share the property of not being searched for in<br>
load-path. =C2=A0So we could probably strengthen the search along the lines=
<br>
you suggest without (hopefully) breaking existing code with a hack along<br=
>
the lines of the one below.<br>
<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan<br>
<br>
<br>
=3D=3D=3D modified file &#39;lisp/subr.el&#39;<br>
--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-04-15 17:03:15 +0000<br>
+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-12 02:15:04 +0000<br>
@@ -1878,10 +1878,15 @@<br>
<div class=3D"">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 load-path (get-load-suffixes)))<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0nil nil<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0t))<br>
- =C2=A0(let ((file (locate-file library<br>
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0(or path load-path)<br>
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0(append (unless nosuffix (get-load-suffixes))<br>
- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load-file-rep-suffixes))))<br>
</div>+ =C2=A0(let* ((suffixes<br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(nconc (unless nosuffix (get-load-suffi=
xes))<br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (when (or (file-n=
ame-absolute-p library)<br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ;; (load &quot;foo.el&quot;) should find /bar/foo.el.gz,<=
br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 ;; but (load &quot;foo&quot;) should not find /bar/foo.gz=
.<br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 (string-match &quot;\\.el\\(\\.[[:alnum:]]+\\)?&quot;<br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 library)=
)<br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 load-file-=
rep-suffixes)))<br>
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (file (locate-file library (or path load-path=
) suffixes)))<br>
<div class=3D"HOEnZb"><div class=3D"h5">=C2=A0 =C2=A0 =C2=A0(if interactive=
-call<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (if file<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message &quot;Library is file %s=
&quot; (abbreviate-file-name file))<br>
<br>
</div></div></blockquote></div><br></div>

--001a1134bdda74595a04f92c7ec7--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 02:18:13 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 22:18:13 2014
Received: from localhost ([127.0.0.1]:59915 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wjfoi-0002fa-Kj
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 22:18:13 -0400
Received: from pruche.dit.umontreal.ca ([132.204.246.22]:54551)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1Wjfof-0002fO-A5
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 22:18:10 -0400
Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242])
 by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id s4C2I4mp022938;
 Sun, 11 May 2014 22:18:05 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 2DFE9601D9; Sun, 11 May 2014 22:18:03 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
Message-ID: <jwv4n0v4ut9.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
Date: Sun, 11 May 2014 22:18:03 -0400
In-Reply-To: <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 17:20:23 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-NAI-Spam-Flag: NO
X-NAI-Spam-Threshold: 5
X-NAI-Spam-Score: 0
X-NAI-Spam-Rules: 1 Rules triggered
	RV4939=0
X-NAI-Spam-Version: 2.3.0.9378 : core <4939> : inlines <853> : streams
 <1180070> : uri <1754400>
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

> 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.

I think I'm beginning to see what you mean.  So far we have simply
considered "if it hurts, don't do it".  And it worked well enough.

> 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?

There are a few (~/.emacs being the most obvious), but admittedly,
I think they all share the property of not being searched for in
load-path.  So we could probably strengthen the search along the lines
you suggest without (hopefully) breaking existing code with a hack along
the lines of the one below.


        Stefan


=== modified file 'lisp/subr.el'
--- lisp/subr.el	2014-04-15 17:03:15 +0000
+++ lisp/subr.el	2014-05-12 02:15:04 +0000
@@ -1878,10 +1878,15 @@
                                        load-path (get-load-suffixes)))
 		     nil nil
 		     t))
-  (let ((file (locate-file library
-			   (or path load-path)
-			   (append (unless nosuffix (get-load-suffixes))
-				   load-file-rep-suffixes))))
+  (let* ((suffixes
+          (nconc (unless nosuffix (get-load-suffixes))
+                 (when (or (file-name-absolute-p library)
+                           ;; (load "foo.el") should find /bar/foo.el.gz,
+                           ;; but (load "foo") should not find /bar/foo.gz.
+                           (string-match "\\.el\\(\\.[[:alnum:]]+\\)?"
+                                         library))
+                   load-file-rep-suffixes)))
+         (file (locate-file library (or path load-path) suffixes)))
     (if interactive-call
 	(if file
 	    (message "Library is file %s" (abbreviate-file-name file))





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 02:03:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 22:03:26 2014
Received: from localhost ([127.0.0.1]:59910 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjfaP-0002C2-Bx
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 22:03:25 -0400
Received: from mail-oa0-f51.google.com ([209.85.219.51]:40830)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjfaM-0002Bf-6U
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 22:03:22 -0400
Received: by mail-oa0-f51.google.com with SMTP id n16so7536984oag.10
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 19:03:16 -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=MZhueeIO9Ov+nLt3AeIwQUPvxbQw5Mn4lGtCscbhML0=;
 b=B0NJAUHqHWCDMgq0Tj/0h3ll65+LUG1o6QYoN6iXU6YmZD2D5oYBHaFhmsD3Z9d2vN
 HFEty5uthdDbMyaMJ4BCqgRO/F24oCTSCuDTbpcDQpIP7ebnRI3SfDm8TA1kcg6ZbFLj
 wn43cdMX5XT8c2Go4fojBR0dSM+0t+HKv3HY1dKJ31LOEH8pYmYYrUI92MKvnYN1E13Y
 89MLF35Zjkl6NyHZA7N+T7nFLX7Xzsfa4B3mGrUDtfgdaL3Jz0wjvBsmaTxqlju0AnSO
 rQfMm3Uj+/rPYz96g9jSHD3uCu4dp6lOO1moUQO5wBzKFCfOEc9dmX29GD+9fHhjDym2
 EGOg==
X-Received: by 10.60.39.131 with SMTP id p3mr30422518oek.44.1399860196447;
 Sun, 11 May 2014 19:03:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 19:02:56 -0700 (PDT)
In-Reply-To: <CAHD9_tTWLY8FnzCBQ18rHix+CmcNYhaD3B-+N_4ednq5QkRE+Q@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
 <ekiopbbzv0.fsf@HIDDEN>
 <CAHD9_tTWLY8FnzCBQ18rHix+CmcNYhaD3B-+N_4ednq5QkRE+Q@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 19:02:56 -0700
X-Google-Sender-Auth: wLj1mdpt3Gj4kdWi2QKKG6zBZqU
Message-ID: <CAHD9_tRdwsCuiCNfVFH1q_Dbt0F+bqE8zae4j_TisgnGxzL6nA@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Glenn Morris <rgm@HIDDEN>
Content-Type: multipart/alternative; boundary=089e0149cc30be9bb104f92a5988
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e0149cc30be9bb104f92a5988
Content-Type: text/plain; charset=UTF-8

I am wondering whether we can deprecate the usage of this function in ways
other than locating libraries? In the case of gnus the call to
locate-library can be simply removed assuming the second parameter of load
is set to t. Gnus will start faster without this redundant load-path
traversal.


On Sun, May 11, 2014 at 6:35 PM, Alex Kosorukoff <alex@HIDDEN> wrote:

> Thank you for the example. You are right, gnus-start.el is using
> locate-library to check existence of its init files and uses load to search
> for them again right after. Given how that code is written, we probably
> should keep locate-library as is since at least some people people are
> relying on its ability to locate arbitrary files that are not libraries.
>
>
> On Sun, May 11, 2014 at 5:32 PM, Glenn Morris <rgm@HIDDEN> wrote:
>
>> Alex Kosorukoff wrote:
>>
>> > 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.
>>
>> I've somewhat lost track of exactly what you want an example of, but:
>>
>>        When Gnus starts, it will read the `gnus-site-init-file'
>>     (`.../site-lisp/gnus-init' by default) and `gnus-init-file' (`~/.gnus'
>>     by default) files.  These are normal Emacs Lisp files and can be used
>>     to avoid cluttering your `~/.emacs' and `site-init' files with Gnus
>>     stuff.  Gnus will also check for files with the same names as these,
>>     but with `.elc' and `.el' suffixes.  In other words, if you have set
>>     `gnus-init-file' to `~/.gnus', it will look for `~/.gnus.elc',
>>     `~/.gnus.el', and finally `~/.gnus' (in this order).
>>
>> and it uses locate-library to do that.
>>
>
>

--089e0149cc30be9bb104f92a5988
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I am wondering whether we can deprecate the usage of this =
function in ways other than locating libraries? In the case of gnus the cal=
l to locate-library can be simply removed assuming the second parameter of =
load is set to t. Gnus will start faster without this redundant load-path t=
raversal.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, May 1=
1, 2014 at 6:35 PM, Alex Kosorukoff <span dir=3D"ltr">&lt;<a href=3D"mailto=
:alex@HIDDEN" target=3D"_blank">alex@HIDDEN</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">

<div dir=3D"ltr">Thank you for the example. You are right, gnus-start.el is=
 using locate-library to check existence of its init files and uses load to=
 search for them again right after. Given how that code is written, we prob=
ably should keep locate-library as is since at least some people people are=
 relying on its ability to locate arbitrary files that are not libraries.</=
div>

<div class=3D"HOEnZb"><div class=3D"h5">
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, May 1=
1, 2014 at 5:32 PM, Glenn Morris <span dir=3D"ltr">&lt;<a href=3D"mailto:rg=
m@HIDDEN" target=3D"_blank">rgm@HIDDEN</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">


<div>Alex Kosorukoff wrote:<br>
<br>
&gt; I think these file names are more appropriate for data files, not<br>
&gt; executable ones. It is undesirable that a name &quot;tramp.gz&quot; wi=
ll shadow a<br>
&gt; valid library file &quot;tramp.elc&quot; that won&#39;t be found as a =
result. When you<br>
&gt; say those names aren&#39;t spurious, do you have a particular =C2=A0ex=
ample of an<br>
&gt; emacs elisp library in mind which file name ends with a suffix other t=
han<br>
&gt; .el .elc .el.gz .elc.gz? I think the main difference is that I assume =
that<br>
&gt; this list is exhaustive and you imply that it is not. You can prove me=
<br>
&gt; wrong by a single example.<br>
<br>
</div>I&#39;ve somewhat lost track of exactly what you want an example of, =
but:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0When Gnus starts, it will read the `gnus-site-in=
it-file&#39;<br>
=C2=A0 =C2=A0 (`.../site-lisp/gnus-init&#39; by default) and `gnus-init-fil=
e&#39; (`~/.gnus&#39;<br>
=C2=A0 =C2=A0 by default) files. =C2=A0These are normal Emacs Lisp files an=
d can be used<br>
=C2=A0 =C2=A0 to avoid cluttering your `~/.emacs&#39; and `site-init&#39; f=
iles with Gnus<br>
=C2=A0 =C2=A0 stuff. =C2=A0Gnus will also check for files with the same nam=
es as these,<br>
=C2=A0 =C2=A0 but with `.elc&#39; and `.el&#39; suffixes. =C2=A0In other wo=
rds, if you have set<br>
=C2=A0 =C2=A0 `gnus-init-file&#39; to `~/.gnus&#39;, it will look for `~/.g=
nus.elc&#39;,<br>
=C2=A0 =C2=A0 `~/.gnus.el&#39;, and finally `~/.gnus&#39; (in this order).<=
br>
<br>
and it uses locate-library to do that.<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--089e0149cc30be9bb104f92a5988--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 01:36:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 21:36:23 2014
Received: from localhost ([127.0.0.1]:59893 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjfAE-0001M2-Ny
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 21:36:23 -0400
Received: from mail-oa0-f43.google.com ([209.85.219.43]:51906)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjfAB-0001Lk-TA
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 21:36:20 -0400
Received: by mail-oa0-f43.google.com with SMTP id l6so7453406oag.2
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 18:36:14 -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=KKbcRAiyPiGcRnFUKBSpob7aY1mooXq/+QaLEkixE78=;
 b=ySzYxRBB309YecSTAbyqRrY+xcUSC/Lzxoc0U5MZa2jaoWYT5N8XoLJ91W/aaKfvt+
 JBrj+tMjX0unrelu9ViCwsL63qfWx+5V+nl9lcd53dcs3s0G6pOtnBhXbOc72a1OprAY
 UTOPQ6Quiz405WLvgjOm7mk0D4C2F38zekxmd1adx/GF4ogf09Wnro0LrQmcHx6yNnT4
 zpNA2//2iGL8dOORyk88GxzS3Dmr1INbTMP+079Sq17PgGyReis4NgiyvayncJAGhitW
 mnty+ZOd9a77UhQD71Dxw/Bf7mvDRNp16B5pkrbccUzVngsiMvQaYQSpVxJhAbXFObm1
 liFg==
X-Received: by 10.182.135.228 with SMTP id pv4mr1754obb.62.1399858574207; Sun,
 11 May 2014 18:36:14 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 18:35:54 -0700 (PDT)
In-Reply-To: <ekiopbbzv0.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
 <ekiopbbzv0.fsf@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 18:35:54 -0700
X-Google-Sender-Auth: ptqvxXk5Jj1UDEODJwj34Vk_egY
Message-ID: <CAHD9_tTWLY8FnzCBQ18rHix+CmcNYhaD3B-+N_4ednq5QkRE+Q@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Glenn Morris <rgm@HIDDEN>
Content-Type: multipart/alternative; boundary=089e0112c5d20d2eb004f929f972
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e0112c5d20d2eb004f929f972
Content-Type: text/plain; charset=UTF-8

Thank you for the example. You are right, gnus-start.el is using
locate-library to check existence of its init files and uses load to search
for them again right after. Given how that code is written, we probably
should keep locate-library as is since at least some people people are
relying on its ability to locate arbitrary files that are not libraries.


On Sun, May 11, 2014 at 5:32 PM, Glenn Morris <rgm@HIDDEN> wrote:

> Alex Kosorukoff wrote:
>
> > 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.
>
> I've somewhat lost track of exactly what you want an example of, but:
>
>        When Gnus starts, it will read the `gnus-site-init-file'
>     (`.../site-lisp/gnus-init' by default) and `gnus-init-file' (`~/.gnus'
>     by default) files.  These are normal Emacs Lisp files and can be used
>     to avoid cluttering your `~/.emacs' and `site-init' files with Gnus
>     stuff.  Gnus will also check for files with the same names as these,
>     but with `.elc' and `.el' suffixes.  In other words, if you have set
>     `gnus-init-file' to `~/.gnus', it will look for `~/.gnus.elc',
>     `~/.gnus.el', and finally `~/.gnus' (in this order).
>
> and it uses locate-library to do that.
>

--089e0112c5d20d2eb004f929f972
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Thank you for the example. You are right, gnus-start.el is=
 using locate-library to check existence of its init files and uses load to=
 search for them again right after. Given how that code is written, we prob=
ably should keep locate-library as is since at least some people people are=
 relying on its ability to locate arbitrary files that are not libraries.</=
div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, May 1=
1, 2014 at 5:32 PM, Glenn Morris <span dir=3D"ltr">&lt;<a href=3D"mailto:rg=
m@HIDDEN" target=3D"_blank">rgm@HIDDEN</a>&gt;</span> wrote:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">

<div class=3D"">Alex Kosorukoff wrote:<br>
<br>
&gt; I think these file names are more appropriate for data files, not<br>
&gt; executable ones. It is undesirable that a name &quot;tramp.gz&quot; wi=
ll shadow a<br>
&gt; valid library file &quot;tramp.elc&quot; that won&#39;t be found as a =
result. When you<br>
&gt; say those names aren&#39;t spurious, do you have a particular =C2=A0ex=
ample of an<br>
&gt; emacs elisp library in mind which file name ends with a suffix other t=
han<br>
&gt; .el .elc .el.gz .elc.gz? I think the main difference is that I assume =
that<br>
&gt; this list is exhaustive and you imply that it is not. You can prove me=
<br>
&gt; wrong by a single example.<br>
<br>
</div>I&#39;ve somewhat lost track of exactly what you want an example of, =
but:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0When Gnus starts, it will read the `gnus-site-in=
it-file&#39;<br>
=C2=A0 =C2=A0 (`.../site-lisp/gnus-init&#39; by default) and `gnus-init-fil=
e&#39; (`~/.gnus&#39;<br>
=C2=A0 =C2=A0 by default) files. =C2=A0These are normal Emacs Lisp files an=
d can be used<br>
=C2=A0 =C2=A0 to avoid cluttering your `~/.emacs&#39; and `site-init&#39; f=
iles with Gnus<br>
=C2=A0 =C2=A0 stuff. =C2=A0Gnus will also check for files with the same nam=
es as these,<br>
=C2=A0 =C2=A0 but with `.elc&#39; and `.el&#39; suffixes. =C2=A0In other wo=
rds, if you have set<br>
=C2=A0 =C2=A0 `gnus-init-file&#39; to `~/.gnus&#39;, it will look for `~/.g=
nus.elc&#39;,<br>
=C2=A0 =C2=A0 `~/.gnus.el&#39;, and finally `~/.gnus&#39; (in this order).<=
br>
<br>
and it uses locate-library to do that.<br>
</blockquote></div><br></div>

--089e0112c5d20d2eb004f929f972--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:42:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 20:42:20 2014
Received: from localhost ([127.0.0.1]:59876 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjeJv-0008IF-9z
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 20:42:19 -0400
Received: from mail-ob0-f172.google.com ([209.85.214.172]:65061)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjeJr-0008Hs-Eo
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 20:42:16 -0400
Received: by mail-ob0-f172.google.com with SMTP id wp18so7345208obc.3
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 17:42:09 -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=/yiO4O6m1lpmZkWCqrRXkkKZMjl4YagE5p0uGWCVc8c=;
 b=oVrJnxOxSNiKhqS3G9VVJN7DNSVoMoCae/DI5Q4hRL57C8QSb3fGNw27CzTeciH/0i
 4cYT/wkYT7b1zOlnoVG3S3TEUWA6RNWa6/+S5eNu0fnwcPivVgTPCaG0B/syMh7uzG74
 iA1qHDq2VydpSrVVRVt05fOkkVBfSO6Kh642Vqpw0gF/6VO8V0xhIy9fn7aHFMJaTWtt
 S+WKKjdbB4cyx5DzYZ+xwuWzRL6tlYa8nWJ2Mndwe+DbpdFPmBHc0K15hOczBsHlqCf6
 Ax6tghyXnt9zVqIg6NZ7GDZY22jSpkXUyvKzflTjS3lz/0kmnbWLjtTObBmupDKlIw1i
 LzTA==
X-Received: by 10.60.102.198 with SMTP id fq6mr29285738oeb.6.1399855329730;
 Sun, 11 May 2014 17:42:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 17:41:48 -0700 (PDT)
In-Reply-To: <jwveh003p2x.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <8361lcuu1f.fsf@HIDDEN>
 <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
 <8338ggus2g.fsf@HIDDEN>
 <CAHD9_tTj9ydkhf+XFWCphq=RLfGiwnxbECJx1noqsNUxTcyyvQ@HIDDEN>
 <831tw0uqyp.fsf@HIDDEN>
 <CAHD9_tQ_m7bVtWJ5GJvkUH2=J1ZX0mZZmHOaRAh9o6FfPfN+Aw@HIDDEN>
 <jwveh003p2x.fsf-monnier+emacsbugs@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 17:41:48 -0700
X-Google-Sender-Auth: E3q0HntCQEW552_O6vtCjUE7vNU
Message-ID: <CAHD9_tQjJi5fWHYnOR1yfdvqzonbn27BpC+AE+BVM+NDathVvQ@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=089e01182752aa690704f929375b
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: Eli Zaretskii <eliz@HIDDEN>, 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e01182752aa690704f929375b
Content-Type: text/plain; charset=UTF-8

On Sun, May 11, 2014 at 3:55 PM, Stefan Monnier <monnier@HIDDEN>wrote:

> > Yes, this makes sense. Here is a patch that the issues you mentioned.
>
> I'm still not sure which situations you want to exclude, so it's hard to
> judge whether your patch does do it...


I exclude anything that is not ending with .el, .elc, .el.gz, or .elc.gz,
for example, my patch won't return any files that have no extension and
will not return files that have only .gz that is not preceded by el or elc.
Otherwise, the latest patch works the same way as the original
locate-library

> +         (locate-file library
> > +                      (or path load-path)
> > +                      (unless (or nosuffix (string-suffix-p ".el.gz"
> library))
>
> ...but special casing ".el.gz" is definitely not a good idea.  Why would
> it need special treatment?
> It's extremely rare for `library' to end in ".el.gz" here.
>

This is because if a user specified .el.gz already, we shouldn't try to
extend it by appending extra suffixes, e.g. looking for .el.gz.el,
el.gz.elc or .el.gz.gz, none of those suffixes can't possibly result in
valid library names. If a user specified only .el or .elc, then we still
can have two options for suffixes ("", ".gz"). If none of the known
suffixes were specified, we have four options produced by
 (get-load-suffixes). BTW, this was not the last patch, it won't apply to
older emacs versions and also not handling .elc.gz (which should not be
extended just like .el.gz). My last patch is using string-match.


>
>
>         Stefan
>

--089e01182752aa690704f929375b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Sun, May 11, 2014 at 3:55 PM, Stefan Monnier <span dir=
=3D"ltr">&lt;<a href=3D"mailto:monnier@HIDDEN" target=3D"_blank">=
monnier@HIDDEN</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"">&gt; Yes, this makes sense. Here is a patc=
h that the issues you mentioned.<br>


<br>
</div>I&#39;m still not sure which situations you want to exclude, so it&#3=
9;s hard to<br>
judge whether your patch does do it...</blockquote><div><br></div><div styl=
e>I exclude anything that is not ending with .el, .elc, .el.gz, or .elc.gz,=
 for example, my patch won&#39;t return any files that have no extension an=
d will not return files that have only .gz that is not preceded by el or el=
c. Otherwise, the latest patch works the same way as the original locate-li=
brary</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div class=3D"">
&gt; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 (locate-file library<br>
&gt; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(or path load-path)<br>
&gt; + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(unless (or nosuffix (string-suffix-p &quot;.el.gz&quot; library)=
)<br>
<br>
</div>...but special casing &quot;.el.gz&quot; is definitely not a good ide=
a. =C2=A0Why would<br>
it need special treatment?<br>
It&#39;s extremely rare for `library&#39; to end in &quot;.el.gz&quot; here=
.<br></blockquote><div><br></div><div style>This is because if a user speci=
fied .el.gz already, we shouldn&#39;t try to extend it by appending extra s=
uffixes, e.g. looking for .el.gz.el, el.gz.elc or .el.gz.gz, none of those =
suffixes can&#39;t possibly result in valid library names. If a user specif=
ied only .el or .elc, then we still can have two options for suffixes (&quo=
t;&quot;, &quot;.gz&quot;). If none of the known suffixes were specified, w=
e have four options produced by =C2=A0(get-load-suffixes). BTW, this was no=
t the last patch, it won&#39;t apply to older emacs versions and also not h=
andling .elc.gz (which should not be extended just like .el.gz). My last pa=
tch is using string-match.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<span class=3D""><font color=3D"#888888"><br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan<br>
</font></span></blockquote></div><br></div></div>

--089e01182752aa690704f929375b--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:32:56 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 20:32:56 2014
Received: from localhost ([127.0.0.1]:59872 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjeAp-00081D-Jr
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 20:32:56 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:54036 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rgm@HIDDEN>) id 1WjeAn-000815-A5
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 20:32:53 -0400
Received: from rgm by fencepost.gnu.org with local (Exim 4.71)
 (envelope-from <rgm@HIDDEN>)
 id 1WjeAl-0002MS-NK; Sun, 11 May 2014 20:32:51 -0400
From: Glenn Morris <rgm@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
X-Spook: Al Jazeera CISU FSF Ruby Ridge Sears Tower propaganda
X-Ran: fy6/2Tgz8OUmmow5_tuxj.$;]#7FIc`")6y'\9>|?/o[j[9lRA23]P~wMtZVoqnKan6bMo
X-Hue: blue
X-Debbugs-No-Ack: yes
X-Attribution: GM
Date: Sun, 11 May 2014 20:32:51 -0400
Message-ID: <ekiopbbzv0.fsf@HIDDEN>
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: -5.7 (-----)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)

Alex Kosorukoff wrote:

> 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.

I've somewhat lost track of exactly what you want an example of, but:

       When Gnus starts, it will read the `gnus-site-init-file'
    (`.../site-lisp/gnus-init' by default) and `gnus-init-file' (`~/.gnus'
    by default) files.  These are normal Emacs Lisp files and can be used
    to avoid cluttering your `~/.emacs' and `site-init' files with Gnus
    stuff.  Gnus will also check for files with the same names as these,
    but with `.elc' and `.el' suffixes.  In other words, if you have set
    `gnus-init-file' to `~/.gnus', it will look for `~/.gnus.elc',
    `~/.gnus.el', and finally `~/.gnus' (in this order).

and it uses locate-library to do that.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:20:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 20:20:53 2014
Received: from localhost ([127.0.0.1]:59868 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjdzA-0007hA-NB
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 20:20:53 -0400
Received: from mail-ob0-f177.google.com ([209.85.214.177]:41189)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1Wjdz7-0007gt-6a
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 20:20:50 -0400
Received: by mail-ob0-f177.google.com with SMTP id gq1so7066082obb.8
 for <17467 <at> 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)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 17:20:23 -0700 (PDT)
In-Reply-To: <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 17:20:23 -0700
X-Google-Sender-Auth: KItpMBUDeGGuV-LGZZHgvnyR8s8
Message-ID: <CAHD9_tTMPFAK1P=4v-z9ZHdKjxFz8ZJV9OcHRszn6UcPHcPm1g@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c1ed8a00852804f928eb3d
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c1ed8a00852804f928eb3d
Content-Type: text/plain; charset=UTF-8

On Sun, May 11, 2014 at 2:56 PM, Stefan Monnier <monnier@HIDDEN>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

<div dir=3D"ltr">On Sun, May 11, 2014 at 2:56 PM, Stefan Monnier <span dir=
=3D"ltr">&lt;<a href=3D"mailto:monnier@HIDDEN" target=3D"_blank">=
monnier@HIDDEN</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote">

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">&gt; The issue is that locat=
e-library returns spurious paths like &quot;.*/tramp&quot; or<br>
&gt; &quot;.*xxx/tramp.gz&quot;<br>
<br>
</div>I don&#39;t see why these are necessarily spurious. =C2=A0Please give=
 very<br>
concrete examples, so as to make it crystal clear why they&#39;re spurious.=
<br></blockquote><div><br></div><div style>I think these file names are mor=
e appropriate for data files, not executable ones. It is undesirable that a=
 name &quot;tramp.gz&quot; will shadow a valid library file &quot;tramp.elc=
&quot; that won&#39;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.</div>

<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"">&gt; This is both unexpected and incorrect given this funct=
ion name and<br>
&gt; spec.<br>
<br>
</div>Unexpected to you, obviously, but I&#39;m not convinced it&#39;s unex=
pected in<br>
general (after all, I don&#39;t remember other bug-reports in this area) an=
d<br>
definitely not incorrect. =C2=A0See the docstring of `load&#39;:<br>
<br>
=C2=A0 =C2=A0Execute a file of Lisp code named FILE.<br>
=C2=A0 =C2=A0First try FILE with `.elc&#39; appended, then try with `.el&#3=
9;,<br>
=C2=A0 =C2=A0then try FILE unmodified (the exact suffixes in the exact orde=
r are<br>
=C2=A0 =C2=A0determined by `load-suffixes&#39;). =C2=A0Environment variable=
 references in<br>
=C2=A0 =C2=A0[...]<br></blockquote><div><br></div><div style>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.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">
Of course, there&#39;s an ambiguity about how the search is performed,<br>
w.r.t. to whether it does:<br>
<br>
=C2=A0 =C2=A0(dolist (s suffixes) (dolist (d load-path) ...)))<br>
or<br>
=C2=A0 =C2=A0(dolist (d load-path) (dolist (s suffixes) ...)))<br>
<br>
We do the second, so that a compiled file in a later directory does not<br>
override a non-compiled file in an earlier directory.<br></blockquote><div>=
<br></div><div style>Yes, I noticed that require won&#39;t attempt to load =
files like &quot;trump&quot; or &quot;trump.gz&quot; 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.</div>

<div style><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"HOEnZb">=
<font color=3D"#888888"><br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan<br>
</font></span></blockquote></div><br></div></div>

--001a11c1ed8a00852804f928eb3d--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 22:55:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 18:55:51 2014
Received: from localhost ([127.0.0.1]:59821 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wjces-0004Mo-Tl
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 18:55:51 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:15477)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1Wjceq-0004Ma-GS
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 18:55:49 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASrA4NMIQ
X-IPAS-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASrA4NMIQ
X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62375417"
Received: from 23-91-155-216.cpe.pppoe.ca (HELO pastel.home) ([23.91.155.216])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 11 May 2014 18:55:42 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id A182A600A4; Sun, 11 May 2014 18:55:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
Message-ID: <jwveh003p2x.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <8361lcuu1f.fsf@HIDDEN>
 <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
 <8338ggus2g.fsf@HIDDEN>
 <CAHD9_tTj9ydkhf+XFWCphq=RLfGiwnxbECJx1noqsNUxTcyyvQ@HIDDEN>
 <831tw0uqyp.fsf@HIDDEN>
 <CAHD9_tQ_m7bVtWJ5GJvkUH2=J1ZX0mZZmHOaRAh9o6FfPfN+Aw@HIDDEN>
Date: Sun, 11 May 2014 18:55:42 -0400
In-Reply-To: <CAHD9_tQ_m7bVtWJ5GJvkUH2=J1ZX0mZZmHOaRAh9o6FfPfN+Aw@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 11:55:18 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 17467
Cc: Eli Zaretskii <eliz@HIDDEN>, 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> Yes, this makes sense. Here is a patch that the issues you mentioned.

I'm still not sure which situations you want to exclude, so it's hard to
judge whether your patch does do it...

> +         (locate-file library
> +                      (or path load-path)
> +                      (unless (or nosuffix (string-suffix-p ".el.gz" library))

...but special casing ".el.gz" is definitely not a good idea.  Why would
it need special treatment?
It's extremely rare for `library' to end in ".el.gz" here.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 22:32:26 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 18:32:26 2014
Received: from localhost ([127.0.0.1]:59811 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjcID-0003jF-L5
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 18:32:26 -0400
Received: from mail-oa0-f41.google.com ([209.85.219.41]:48993)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjcIA-0003iz-VY
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 18:32:23 -0400
Received: by mail-oa0-f41.google.com with SMTP id m1so7332137oag.14
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 15:32:17 -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=TrxSMnoTrQBLMmX3HMUv19aKkicL7zm5C8letFCyqI8=;
 b=mvg6HGyC76bi1rjneNhf6HGZTNfbhASVQdzW1qmDmYd/JDy+BTziKdhCq35YNdVSCv
 Jc7PAInHYKGfuu9A2S7zI2061Y5BZmH7X7P/KtJLy+f3u5jicTfaCJEj0v2bdt7S1Jv4
 jzoqYLrLAp52VOtyPS6IawS1TfIhLjGRBMZkVhNn96o5qep0AahnnSjnP50hsOTa4SPW
 30yduYlDbmTCHc96TV5kGwdK1bF3royjg6nEs3+1jA1iqoLohTmrkLvMFnNSZQUmocfH
 WcMHxPjT2wxGiiJEoMYsmYYqSvKjpM1Zwtnmgyjj/xiwEpP/PrSxIAt3O7eLLoviBbsD
 SEUw==
X-Received: by 10.60.102.198 with SMTP id fq6mr28843060oeb.6.1399847537058;
 Sun, 11 May 2014 15:32:17 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 15:31:56 -0700 (PDT)
In-Reply-To: <3feh00ko79.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 <3feh00ko79.fsf@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 15:31:56 -0700
X-Google-Sender-Auth: ehrs65wUy9dNIRHueZGlzaWmgms
Message-ID: <CAHD9_tQYOm2sJbzX6DkcZemepHmQ6nSFryeEqYwNFU2Xixg8eA@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Glenn Morris <rgm@HIDDEN>
Content-Type: multipart/alternative; boundary=089e011827522faab404f92767a2
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e011827522faab404f92767a2
Content-Type: text/plain; charset=UTF-8

I think you are overlooking something. If I notice a random tramp.el in
some unusual place, I will investigate it right away because I know .el
files can be executed by emacs. I wouldn't do it for a random data file
without extension or a compressed .gz archive unless they have executable
permission for some unknown reason. Data files are created by many
applications and it is concerning me as long as no program I frequently use
will execute them randomly. You can say that data files should never be in
the load-path of emacs and I will agree with you. However, I can see
scenarios when this can happen unintentionally. It would be careless not to
try to add a simple safeguard to prevent this kind of execution.

I did fix the proximal cause already, worked around this function and
patched my emacs, so this bug doesn't affect me in any way now. Now I am
trying hard to fix the root cause. This is why I reported this bug, shared
my patches and addressed all valid concerns that were expressed here, even
those that aren't that important for me personally. The most difficult part
seems to be in persuading developers that this is an issue to be fixed. If
I fail at this, I simply will be less confident in using emacs.



On Sun, May 11, 2014 at 2:19 PM, Glenn Morris <rgm@HIDDEN> wrote:

> Alex Kosorukoff wrote:
>
> > It can cause user inconvenience or pose a security/privacy issue
> > because a random file named "tramp" or "tramp.gz" placed in some
> > directory of the load-path can be loaded instead of the standard
> > library without user knowledge.
>
> This argument does not fly, because if someone can write a "tramp" file
> to a directory in your load-path, they can just as easily write
> "tramp.el". Random files should not be being written to your load-path,
> and you should not be adding inappropriate directories to that path.
> Your immediate problem was having ~/.emacs.d in load-path.
>

--089e011827522faab404f92767a2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style>I think you are overlooking something. If I not=
ice a random tramp.el in some unusual place, I will investigate it right aw=
ay because I know .el files can be executed by emacs. I wouldn&#39;t do it =
for a random data file without extension or a compressed .gz archive unless=
 they have executable permission for some unknown reason. Data files are cr=
eated by many applications and it is concerning me as long as no program I =
frequently use will execute them randomly. You can say that data files shou=
ld never be in the load-path of emacs and I will agree with you. However, I=
 can see scenarios when this can happen unintentionally. It would be carele=
ss not to try to add a simple safeguard to prevent this kind of execution.<=
/div>

<div><br></div>I did fix the proximal cause already, worked around this fun=
ction and patched my emacs, so this bug doesn&#39;t affect me in any way no=
w. Now I am trying hard to fix the root cause. This is why I reported this =
bug, shared my patches and addressed all valid concerns that were expressed=
 here, even those that aren&#39;t that important for me personally. The mos=
t difficult part seems to be in persuading developers that this is an issue=
 to be fixed. If I fail at this, I simply will be less confident in using e=
macs.<div>

<br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quot=
e">On Sun, May 11, 2014 at 2:19 PM, Glenn Morris <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:rgm@HIDDEN" target=3D"_blank">rgm@HIDDEN</a>&gt;</span> wro=
te:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">Alex Kosorukoff wrote:<br>
<br>
&gt; It can cause user inconvenience or pose a security/privacy issue<br>
&gt; because a random file named &quot;tramp&quot; or &quot;tramp.gz&quot; =
placed in some<br>
&gt; directory of the load-path can be loaded instead of the standard<br>
&gt; library without user knowledge.<br>
<br>
</div>This argument does not fly, because if someone can write a &quot;tram=
p&quot; file<br>
to a directory in your load-path, they can just as easily write<br>
&quot;tramp.el&quot;. Random files should not be being written to your load=
-path,<br>
and you should not be adding inappropriate directories to that path.<br>
Your immediate problem was having ~/.emacs.d in load-path.<br>
</blockquote></div><br></div>

--089e011827522faab404f92767a2--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 21:56:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 17:56:23 2014
Received: from localhost ([127.0.0.1]:59789 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjbjK-0001dl-KN
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 17:56:22 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:55349)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WjbjJ-0001dW-4R
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 17:56:21 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASUYpYhg0wh
X-IPAS-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASUYpYhg0wh
X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62369312"
Received: from 23-91-155-216.cpe.pppoe.ca (HELO pastel.home) ([23.91.155.216])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 11 May 2014 17:56:15 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 3AC48600A4; Sun, 11 May 2014 17:56:15 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
Message-ID: <jwvppjk3s3p.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
Date: Sun, 11 May 2014 17:56:15 -0400
In-Reply-To: <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 13:45:12 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> 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.

> 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
   [...]

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.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 21:19:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 17:19:59 2014
Received: from localhost ([127.0.0.1]:59752 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjbA6-0000gB-VF
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 17:19:59 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:51974 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rgm@HIDDEN>) id 1WjbA4-0000g2-2l
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 17:19:56 -0400
Received: from rgm by fencepost.gnu.org with local (Exim 4.71)
 (envelope-from <rgm@HIDDEN>)
 id 1WjbA2-0007oe-UE; Sun, 11 May 2014 17:19:54 -0400
From: Glenn Morris <rgm@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
X-Spook: JUWTF AFSPC terrorism anarchy asset Mafia Mahmoud
X-Ran: rDDsw({HneP*<&ioG4S`[p.}X.vJq=69AHUBpjLzN0@X*n#{U9N=m>qABe*t5Rl[sNPbsY
X-Hue: magenta
X-Debbugs-No-Ack: yes
X-Attribution: GM
Date: Sun, 11 May 2014 17:19:54 -0400
In-Reply-To: <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 13:45:12 -0700")
Message-ID: <3feh00ko79.fsf@HIDDEN>
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: -5.7 (-----)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org, Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)

Alex Kosorukoff wrote:

> It can cause user inconvenience or pose a security/privacy issue
> because a random file named "tramp" or "tramp.gz" placed in some
> directory of the load-path can be loaded instead of the standard
> library without user knowledge.

This argument does not fly, because if someone can write a "tramp" file
to a directory in your load-path, they can just as easily write
"tramp.el". Random files should not be being written to your load-path,
and you should not be adding inappropriate directories to that path.
Your immediate problem was having ~/.emacs.d in load-path.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 21:01:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 17:01:19 2014
Received: from localhost ([127.0.0.1]:59737 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wjas1-0007VZ-Sx
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 17:01:18 -0400
Received: from mail-ob0-f169.google.com ([209.85.214.169]:36969)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1Wjary-0007VK-O5
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 17:01:16 -0400
Received: by mail-ob0-f169.google.com with SMTP id vb8so7329318obc.28
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 14:01:09 -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=JHGwByidM7+NOfXRa4/G9ajVaa6dp/4G7axjT+omHjc=;
 b=QB7eX5yXcLMiBXg6F41NKooxVZyEzvgdnbv8Wf9ptvJKM0Cy/zr39vGBb0fcVhG2F6
 ohkRUFX0e75hCPHMYCh0hdvYiYoXKufFtRAZiIxR/OpUR1qZiDJ803EGRUH125J4H7b8
 BMi6q4QWXo2qDjz5iDfBdfGy8LZBLqbJ6u+i6pwOrFLaZDFbJ+k6v1nuDo3BIJfKybkV
 yfE2NbqSUFTVCjI65qsu8Bp3C+cOpBQTEKkj67ptkyMrtlE5933CVSpy3QOe+shb77HS
 wzRxBYBhxVzZPP7A0tqbHytkZvCMf3jY1tjtw2nF1QsvmDTedYuXVKjFxA9eX2+2e9n9
 Kdbw==
X-Received: by 10.182.35.99 with SMTP id g3mr17980985obj.43.1399842068927;
 Sun, 11 May 2014 14:01:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 14:00:48 -0700 (PDT)
In-Reply-To: <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
 <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 14:00:48 -0700
X-Google-Sender-Auth: MORjKJOzzDlhJdYJPJjrpPC99rk
Message-ID: <CAHD9_tTB962QcG6tuhVw-92G0qfjsDUfoU7=sjBfC-DcSaUv2w@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=e89a8f502d04429a1204f9262149
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.4 (/)

--e89a8f502d04429a1204f9262149
Content-Type: text/plain; charset=UTF-8

Stefan is right that the bug was there for a long time. I would like my
patch be compatible with older versions of emacs that don't have
string-suffix-p, so here is the revised version

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: alex@HIDDEN
# target_branch: :parent
# testament_sha1: d9ca6f57d0d8486d42ed77a739877a208a34f22e
# timestamp: 2014-05-11 13:55:53 -0700
# base_revision_id: monnier@HIDDEN\
#   1mzcrftziwhrw9hl
#
# Begin patch
=== modified file 'lisp/subr.el'
--- lisp/subr.el        2014-04-09 01:48:07 +0000
+++ lisp/subr.el        2014-05-11 20:55:38 +0000
@@ -1857,10 +1857,14 @@
                                        load-path (get-load-suffixes)))
                     nil nil
                     t))
-  (let ((file (locate-file library
-                          (or path load-path)
-                          (append (unless nosuffix (get-load-suffixes))
-                                  load-file-rep-suffixes))))
+  (let ((file
+         (locate-file library
+                      (or path load-path)
+                      (unless (or nosuffix
+                                  (string-match "\\.elc?\\.gz\\'" library))
+                        (if (string-match "\\.elc?\\'" library)
+                            load-file-rep-suffixes
+                          (get-load-suffixes))))))
     (if interactive-call
        (if file
            (message "Library is file %s" (abbreviate-file-name file))

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWfbc99AABHZ/gDIwFUFQ4//3
8wgABL////BgBs96932joSoL3t0q2rG2TpgbVEE2kE9J6jNTyaZNNTagHqAAaaeoOYBNMAmQwABM
EwAAAShU02oAA0AAANAAAAG0qNQNT1MTCaepgmgwBDAI0000EUgRMgalP2mqaZpPVP0U9T0h6jah
kGJo0EVE0aaRgITaJMJoaRieoNAAZMyxwwqXQuSoc5zx7XqLgxjChKpd+GuM3swscixOW2FuYpwb
BJ76XVaN7ooEkNIl8j4H03G7ZaZmUngNpcGMaPziEkCQaXe13WIEZAjrzUVAplMmPv1v9TyDhZk/
TOCTEDcwOWPX5fOPrmzaublzrn8a9huAiuc8PAHYZNSwwjGhSFdSjC5SpYYbMwwpQrOXBEKJ3iZF
xMl+oRaRFCFZtuLh4YuClOwDzJ2cWwwkZCevW+rQM0X3eaEPAlD5B1eGOUYxZmw4cVlwgMkDZ3GZ
9AtqjnMIiLHfetqjn0CpARpIshrEt/05xJEWdXxLOe+NJoQjuMKkKlnUWzmFb+kN1g6CdRNKmoiP
XNismTs0wuRr35bDn4u+xGCEADgWqFbY5VAay3aHG6u7TB4iYIfEL7zJwFZoUJUM3c3+8duzI+Gw
TRDux3mtEOw6Q5pQdWZPmJiOJlrCNKcdm2BaHY/HpUhRgK0QoJtiadSVUybnyQxg9d/ZQTHS+Btw
7CqlMt1Lxhg65OAldu/FyOViFxXEMItpVgQNeBKhvHO8sS5hrOBR0qqutnrT+EWImQ5V23kQTlqx
Fd9ZIWwiyGqDeRU13oRurcJn2BtgIL6CS1uqhvgeodpiWMd+vZDjQTDE0HY5Uw6xPQahmK4du8xy
e2W5sXMjaOdRESRqGFxkVnUTqMqHoxIuLpmP/IdEJHApoJ1apwziupdVOEDpGWxWb7DEuLlM22QQ
HWza0l7xPf4ZYl72QOl+XZuqKiVvBkUiubNTzGuZihbGiGqmcryB2wyacpyqEoJRh29sQJmtZiZt
pFszcI94kc6nnwLmkkNifK9vqQuobBWhKhQLtXdG0hlrVXIqIOQyLL7DDcxheex8xPZKdjEMEytU
kzdrE3WxZsyEoyQhsxQbhLXMO90f2G6WyRYpm24mRjLZxKxYWUQXErpKlSbSTY97XjMdYvvZlTZD
ORCO615GiQTND6RrmmfrsoU7lnoZ3CefiGW4rk+sSgcjiR1pBIiSQSIl8np6nm2uInuxVqAqHwHE
JEX3WHA5m230El7Dobc9lW9l4cvcho8QPqh+IniDxPK2HCHlOtFMzOlPwPMOD0Dwz1a9DjU9BJY5
6Fu/mfa9fCHJF+x+5uqFMjn7XfhnHuG9j3JLFes6IXnEraIXdKYTeJGspva7eg4iYPXVDDsTQIC8
33xlGuvV5sEqFJROfJ8nfWm5hFm3CeftDC7At8jwuQx6fiWIcubjY+8XkVBUCgvxQFK2tK6JPofR
GtSFpRcJMQsVOp9gac33JNjR5jHMwBkAF6FH0LjRk7eT2aVLnZXFKQzqcSa6aDGntmRuUjRktEnl
aYpEbgXl2ntPa+jrU8dyLMNHsYaBmPkjiePIfAzO4h74eQO7ufN0Q7m15CQ20vAho8n6oQYhY6He
PMGoez7BMLgn0dGTqD8w94OT7Xm4P0YATa8hPUJ0DV4iZvRTYT1BBG4G5iL3ofJUtGxmnAcINyKK
RiV4/OVmEEKc04jYhEogyEkyCxDg9zkPa2ZhrCrIe9tUHFqzEqYJR0C0ZBY8EN6tQTihBDreFEMA
I+L8OoATB73QCwNXyE6u8EPlUh9Xg55E3LzE1vD1MMIRaY3OPGzghoJUiPyQxToJATEmpuCquN72
uweLq6XhgqGgSnuatYGAljGDRArjU6IiSlO1ptukSJDJ56MbIvaNyFhNA5vvYbODvIItsG+ODIqJ
Nm/oO5mMna3j7GiYdriN4mpGAiTOSG57XmhYhpBT4CSfgFrwa/WJ6IbkOAPkk2F749yGCFJM2CQR
YDBCaBWJ8xMR8RLx3eg6R4+TvDDZwf/F3JFOFCQ9tz30AA==





On Sun, May 11, 2014 at 1:45 PM, Alex Kosorukoff <alex@HIDDEN> wrote:

> The issue is that locate-library returns spurious paths like ".*/tramp" or
> ".*xxx/tramp.gz" instead of returning a valid path to the library or nil if
> no matching path is found. This is both unexpected and incorrect given this
> function name and spec. It can cause user inconvenience or pose a
> security/privacy issue because a random file named "tramp" or "tramp.gz"
> placed in some directory of the load-path can be loaded instead of the
> standard library without user knowledge. This is why I would prefer to fix
> it.
>
> On Sun, May 11, 2014 at 12:50 PM, Stefan Monnier <monnier@HIDDEN
> > wrote:
>
>> > it should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is
>> nil.
>>
>> Why?
>> Did you find some documentation indicating that this is how it should
>> work?
>> Or is it the behavior you'd prefer, and if so, can you explain why you'd
>> prefer that behavior?  Which concrete cases do you specifically care
>> about?
>>
>
> This was the first and simplest way to address the issue above. Eli
> Zaretskii made a valid point that it is not consistent with the way this
> function worked before and not the most convenient for the user. I agree
> with this, so I posted a patch that handles the cases he described, except
> that it addresses the issue above.
>
>>
>> The current behavior has been in use for *many* years and I expect that
>> a fair bit of code relies on it, so we'd need a really good reason to
>> change it.  Maybe we can accommodate your specific concrete cases in
>> some other way.
>>
>
> I understand that the bug was there for many years and many
> people implemented workarounds (I did). I don't think this is a valid
> reason to keep it though. We just need to be careful to make sure we don't
> introduce a regression while fixing it. Unit tests can help.
>
>
>>
>>
>>         Stefan
>>
>
>

--e89a8f502d04429a1204f9262149
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Stefan is right that the bug was there for a long time. I =
would like my patch be compatible with older versions of emacs that don&#39=
;t have string-suffix-p, so here is the revised version<div><br></div><div>

<div># Bazaar merge directive format 2 (Bazaar 0.90)</div><div># revision_i=
d: alex@HIDDEN</div><div># target_branch=
: :parent</div><div># testament_sha1: d9ca6f57d0d8486d42ed77a739877a208a34f=
22e</div>

<div># timestamp: 2014-05-11 13:55:53 -0700</div><div># base_revision_id: m=
onnier@HIDDEN\</div><div># =C2=A0 1mzcrftziwhrw9h=
l</div><div>#=C2=A0</div><div># Begin patch</div><div>=3D=3D=3D modified fi=
le &#39;lisp/subr.el&#39;</div>

<div>--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-04-09 01:48:07 +0000<=
/div><div>+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-11 20:55:38 +=
0000</div><div>@@ -1857,10 +1857,14 @@</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 load-path (get-load-suffixes)))</=
div>

<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0nil nil</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0t))</div><div>- =C2=A0(let ((file (locate-file l=
ibrary</div><div>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or path load-path)</div><div>- =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(append (unless nosuffix (get-load-suffixes))</div>

<div>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load-file-rep-suffixes)=
)))</div><div>+ =C2=A0(let ((file</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (=
locate-file library</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or path load-path)</div><div>+ =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(unles=
s (or nosuffix</div>

<div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(string-match &quot;\\.=
elc?\\.gz\\&#39;&quot; library))</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (string-match &q=
uot;\\.elc?\\&#39;&quot; library)</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load-f=
ile-rep-suffixes</div>

<div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0(get-load-suffixes))))))</div><div>=C2=A0 =C2=A0 =
=C2=A0(if interactive-call</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (if file</=
div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message &quot;Library i=
s file %s&quot; (abbreviate-file-name file))</div><div>

<br></div><div># Begin bundle</div><div>IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY=
0CiMKQlpoOTFBWSZTWfbc99AABHZ/gDIwFUFQ4//3</div><div>8wgABL////BgBs96932joSo=
L3t0q2rG2TpgbVEE2kE9J6jNTyaZNNTagHqAAaaeoOYBNMAmQwABM</div><div>EwAAAShU02o=
AA0AAANAAAAG0qNQNT1MTCaepgmgwBDAI0000EUgRMgalP2mqaZpPVP0U9T0h6jah</div>

<div>kGJo0EVE0aaRgITaJMJoaRieoNAAZMyxwwqXQuSoc5zx7XqLgxjChKpd+GuM3swscixOW2=
FuYpwb</div><div>BJ76XVaN7ooEkNIl8j4H03G7ZaZmUngNpcGMaPziEkCQaXe13WIEZAjrzU=
VAplMmPv1v9TyDhZk/</div><div>TOCTEDcwOWPX5fOPrmzaublzrn8a9huAiuc8PAHYZNSwwj=
GhSFdSjC5SpYYbMwwpQrOXBEKJ3iZF</div>

<div>xMl+oRaRFCFZtuLh4YuClOwDzJ2cWwwkZCevW+rQM0X3eaEPAlD5B1eGOUYxZmw4cVlwgM=
kDZ3GZ</div><div>9AtqjnMIiLHfetqjn0CpARpIshrEt/05xJEWdXxLOe+NJoQjuMKkKlnUWz=
mFb+kN1g6CdRNKmoiP</div><div>XNismTs0wuRr35bDn4u+xGCEADgWqFbY5VAay3aHG6u7TB=
4iYIfEL7zJwFZoUJUM3c3+8duzI+Gw</div>

<div>TRDux3mtEOw6Q5pQdWZPmJiOJlrCNKcdm2BaHY/HpUhRgK0QoJtiadSVUybnyQxg9d/ZQT=
HS+Btw</div><div>7CqlMt1Lxhg65OAldu/FyOViFxXEMItpVgQNeBKhvHO8sS5hrOBR0qqutn=
rT+EWImQ5V23kQTlqx</div><div>Fd9ZIWwiyGqDeRU13oRurcJn2BtgIL6CS1uqhvgeodpiWM=
d+vZDjQTDE0HY5Uw6xPQahmK4du8xy</div>

<div>e2W5sXMjaOdRESRqGFxkVnUTqMqHoxIuLpmP/IdEJHApoJ1apwziupdVOEDpGWxWb7DEuL=
lM22QQ</div><div>HWza0l7xPf4ZYl72QOl+XZuqKiVvBkUiubNTzGuZihbGiGqmcryB2wyacp=
yqEoJRh29sQJmtZiZt</div><div>pFszcI94kc6nnwLmkkNifK9vqQuobBWhKhQLtXdG0hlrVX=
IqIOQyLL7DDcxheex8xPZKdjEMEytU</div>

<div>kzdrE3WxZsyEoyQhsxQbhLXMO90f2G6WyRYpm24mRjLZxKxYWUQXErpKlSbSTY97XjMdYv=
vZlTZD</div><div>ORCO615GiQTND6RrmmfrsoU7lnoZ3CefiGW4rk+sSgcjiR1pBIiSQSIl8n=
p6nm2uInuxVqAqHwHE</div><div>JEX3WHA5m230El7Dobc9lW9l4cvcho8QPqh+IniDxPK2HC=
HlOtFMzOlPwPMOD0Dwz1a9DjU9BJY5</div>

<div>6Fu/mfa9fCHJF+x+5uqFMjn7XfhnHuG9j3JLFes6IXnEraIXdKYTeJGspva7eg4iYPXVDD=
sTQIC8</div><div>33xlGuvV5sEqFJROfJ8nfWm5hFm3CeftDC7At8jwuQx6fiWIcubjY+8XkV=
BUCgvxQFK2tK6JPofR</div><div>GtSFpRcJMQsVOp9gac33JNjR5jHMwBkAF6FH0LjRk7eT2a=
VLnZXFKQzqcSa6aDGntmRuUjRktEnl</div>

<div>aYpEbgXl2ntPa+jrU8dyLMNHsYaBmPkjiePIfAzO4h74eQO7ufN0Q7m15CQ20vAho8n6oQ=
YhY6He</div><div>PMGoez7BMLgn0dGTqD8w94OT7Xm4P0YATa8hPUJ0DV4iZvRTYT1BBG4G5i=
L3ofJUtGxmnAcINyKK</div><div>RiV4/OVmEEKc04jYhEogyEkyCxDg9zkPa2ZhrCrIe9tUHF=
qzEqYJR0C0ZBY8EN6tQTihBDreFEMA</div>

<div>I+L8OoATB73QCwNXyE6u8EPlUh9Xg55E3LzE1vD1MMIRaY3OPGzghoJUiPyQxToJATEmpu=
CquN72</div><div>uweLq6XhgqGgSnuatYGAljGDRArjU6IiSlO1ptukSJDJ56MbIvaNyFhNA5=
vvYbODvIItsG+ODIqJ</div><div><div>Nm/oO5mMna3j7GiYdriN4mpGAiTOSG57XmhYhpBT4=
CSfgFrwa/WJ6IbkOAPkk2F749yGCFJM2CQR</div>

<div>YDBCaBWJ8xMR8RLx3eg6R4+TvDDZwf/F3JFOFCQ9tz30AA=3D=3D</div></div><div><=
br></div><div><br></div><div><br></div></div></div><div class=3D"gmail_extr=
a"><br><br><div class=3D"gmail_quote">On Sun, May 11, 2014 at 1:45 PM, Alex=
 Kosorukoff <span dir=3D"ltr">&lt;<a href=3D"mailto:alex@HIDDEN" target=
=3D"_blank">alex@HIDDEN</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>The issue is that loca=
te-library returns spurious paths like &quot;.*/tramp&quot; or &quot;.*xxx/=
tramp.gz&quot; instead of returning a valid path to the library or nil if n=
o matching path is found. This is both unexpected and incorrect given this =
function name and spec. It can cause user inconvenience or pose a security/=
privacy issue because a random file named &quot;tramp&quot; or &quot;tramp.=
gz&quot; placed in some directory of the load-path can be loaded instead of=
 the standard library without user knowledge. This is why I would prefer to=
 fix it.</div>


<div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div c=
lass=3D"">On Sun, May 11, 2014 at 12:50 PM, Stefan Monnier <span dir=3D"ltr=
">&lt;<a href=3D"mailto:monnier@HIDDEN" target=3D"_blank">monnier=
@iro.umontreal.ca</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>&gt; it should be just (&quot;.elc&quot; &quot;.elc.g=
z&quot; &quot;.el&quot; &quot;.el.gz&quot;) when nosuffix is nil.<br>



<br>
</div>Why?<br>
Did you find some documentation indicating that this is how it should work?=
<br>
Or is it the behavior you&#39;d prefer, and if so, can you explain why you&=
#39;d<br>
prefer that behavior? =C2=A0Which concrete cases do you specifically care a=
bout?<br></blockquote><div><br></div></div><div>This was the first and simp=
lest way to address the issue above.=C2=A0Eli Zaretskii made a valid point =
that it is not consistent with the way this function worked before and not =
the most convenient for the user. I agree with this, so I posted a patch th=
at handles the cases he described, except that it addresses the issue above=
.</div>

<div class=3D"">
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
The current behavior has been in use for *many* years and I expect that<br>
a fair bit of code relies on it, so we&#39;d need a really good reason to<b=
r>
change it. =C2=A0Maybe we can accommodate your specific concrete cases in<b=
r>
some other way.<br></blockquote><div><br></div></div><div>I understand that=
 the bug was there for many years and many people=C2=A0implemented workarou=
nds (I did). I don&#39;t think this is a valid reason to keep it though. We=
 just need to be careful to make sure we don&#39;t introduce a regression w=
hile fixing it. Unit tests can help.</div>


<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<span><font color=3D"#888888"><br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan<br>
</font></span></blockquote></div><br></div></div>
</blockquote></div><br></div>

--e89a8f502d04429a1204f9262149--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 20:45:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 16:45:43 2014
Received: from localhost ([127.0.0.1]:59721 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1Wjacw-000745-7M
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 16:45:43 -0400
Received: from mail-oa0-f42.google.com ([209.85.219.42]:35639)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1Wjacs-00073n-U8
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 16:45:39 -0400
Received: by mail-oa0-f42.google.com with SMTP id j17so7361714oag.1
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 13:45:33 -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=WVARWsNedNObe9qih4Lo5QNnVqUkmMM4Y+JWDuZf8mM=;
 b=H0u+G111WXDDXzcEbygmEdRdaGqCyXnV/HYzY88kqXh1wl1m80HRwtMHmnMRckfsUm
 RSITBLcivlJ/cSVShUtCtNRPVP00KxtkYeIE/0aSuJ/ITXbnoWqm0Vw+a29+QP4kpXz/
 sADQdYQxy6Tz24z5vE+qGEn4pOcz9lBNuRmEWRbNXthMu3qHc0ZDzRUapsORuAj2f8zy
 q/3slK2WJ9IYc1afYsYjuA5sq6UzBIjZbFSelYbGJqc83TfKRKk2ScmLKhKzb2ONqeIi
 FH3pGY1HIyGFeBJNN6OET4kg5sdElfGuVyZZVTsFD5EsumzV/ioFUQy/ShXgYzH5Yyj+
 MDzg==
X-Received: by 10.60.39.131 with SMTP id p3mr29313233oek.44.1399841132930;
 Sun, 11 May 2014 13:45:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 13:45:12 -0700 (PDT)
In-Reply-To: <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 13:45:12 -0700
X-Google-Sender-Auth: 4wpv_lDMvdUna5y-rGHh8iw4Rxo
Message-ID: <CAHD9_tRx8Gx58xdTkgMkOK-=p0ZurHEVCH90FHhq6yEjHkywng@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Stefan Monnier <monnier@HIDDEN>
Content-Type: multipart/alternative; boundary=089e0149cc30786b1704f925e9f8
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--089e0149cc30786b1704f925e9f8
Content-Type: text/plain; charset=UTF-8

The issue is that locate-library returns spurious paths like ".*/tramp" or
".*xxx/tramp.gz" instead of returning a valid path to the library or nil if
no matching path is found. This is both unexpected and incorrect given this
function name and spec. It can cause user inconvenience or pose a
security/privacy issue because a random file named "tramp" or "tramp.gz"
placed in some directory of the load-path can be loaded instead of the
standard library without user knowledge. This is why I would prefer to fix
it.

On Sun, May 11, 2014 at 12:50 PM, Stefan Monnier
<monnier@HIDDEN>wrote:

> > it should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is nil.
>
> Why?
> Did you find some documentation indicating that this is how it should work?
> Or is it the behavior you'd prefer, and if so, can you explain why you'd
> prefer that behavior?  Which concrete cases do you specifically care about?
>

This was the first and simplest way to address the issue above. Eli
Zaretskii made a valid point that it is not consistent with the way this
function worked before and not the most convenient for the user. I agree
with this, so I posted a patch that handles the cases he described, except
that it addresses the issue above.

>
> The current behavior has been in use for *many* years and I expect that
> a fair bit of code relies on it, so we'd need a really good reason to
> change it.  Maybe we can accommodate your specific concrete cases in
> some other way.
>

I understand that the bug was there for many years and many
people implemented workarounds (I did). I don't think this is a valid
reason to keep it though. We just need to be careful to make sure we don't
introduce a regression while fixing it. Unit tests can help.


>
>
>         Stefan
>

--089e0149cc30786b1704f925e9f8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style>The issue is that locate-library returns spurio=
us paths like &quot;.*/tramp&quot; or &quot;.*xxx/tramp.gz&quot; instead of=
 returning a valid path to the library or nil if no matching path is found.=
 This is both unexpected and incorrect given this function name and spec. I=
t can cause user inconvenience or pose a security/privacy issue because a r=
andom file named &quot;tramp&quot; or &quot;tramp.gz&quot; placed in some d=
irectory of the load-path can be loaded instead of the standard library wit=
hout user knowledge. This is why I would prefer to fix it.</div>

<div style><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Sun, May 11, 2014 at 12:50 PM, Stefan Monnier <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:monnier@HIDDEN" target=3D"_blank">monnier@HIDDEN=
real.ca</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div class=3D"">&gt; it should be just (&quot;.elc&quot; &=
quot;.elc.gz&quot; &quot;.el&quot; &quot;.el.gz&quot;) when nosuffix is nil=
.<br>


<br>
</div>Why?<br>
Did you find some documentation indicating that this is how it should work?=
<br>
Or is it the behavior you&#39;d prefer, and if so, can you explain why you&=
#39;d<br>
prefer that behavior? =C2=A0Which concrete cases do you specifically care a=
bout?<br></blockquote><div><br></div><div style>This was the first and simp=
lest way to address the issue above.=C2=A0Eli Zaretskii made a valid point =
that it is not consistent with the way this function worked before and not =
the most convenient for the user. I agree with this, so I posted a patch th=
at handles the cases he described, except that it addresses the issue above=
.</div>

<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
<br>
The current behavior has been in use for *many* years and I expect that<br>
a fair bit of code relies on it, so we&#39;d need a really good reason to<b=
r>
change it. =C2=A0Maybe we can accommodate your specific concrete cases in<b=
r>
some other way.<br></blockquote><div><br></div><div>I understand that the b=
ug was there for many years and many people=C2=A0implemented workarounds (I=
 did). I don&#39;t think this is a valid reason to keep it though. We just =
need to be careful to make sure we don&#39;t introduce a regression while f=
ixing it. Unit tests can help.</div>

<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex">
<span class=3D""><font color=3D"#888888"><br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan<br>
</font></span></blockquote></div><br></div></div>

--089e0149cc30786b1704f925e9f8--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 19:50:25 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 15:50:25 2014
Received: from localhost ([127.0.0.1]:59662 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjZlQ-0005Wr-LE
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 15:50:25 -0400
Received: from ironport2-out.teksavvy.com ([206.248.154.181]:56278)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <monnier@HIDDEN>) id 1WjZlN-0005WV-Js
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 15:50:22 -0400
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASrA4NMIQ
X-IPAS-Result: ArUGAIDvNVMXW5vY/2dsb2JhbABZgwaDSsA9gRcXdIIlAQEBAQIBViMFCws0EhQYDSSIBAjSGReOegeEOASrA4NMIQ
X-IronPort-AV: E=Sophos;i="4.97,753,1389762000"; d="scan'208";a="62362591"
Received: from 23-91-155-216.cpe.pppoe.ca (HELO pastel.home) ([23.91.155.216])
 by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA;
 11 May 2014 15:50:15 -0400
Received: by pastel.home (Postfix, from userid 20848)
 id 733D3602A0; Sun, 11 May 2014 15:50:15 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
Message-ID: <jwvha4w5caz.fsf-monnier+emacsbugs@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
Date: Sun, 11 May 2014 15:50:15 -0400
In-Reply-To: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 09:06:10 -0700")
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.3 (/)

> it should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is nil.

Why?
Did you find some documentation indicating that this is how it should work?
Or is it the behavior you'd prefer, and if so, can you explain why you'd
prefer that behavior?  Which concrete cases do you specifically care about?

The current behavior has been in use for *many* years and I expect that
a fair bit of code relies on it, so we'd need a really good reason to
change it.  Maybe we can accommodate your specific concrete cases in
some other way.


        Stefan




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 18:55:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 14:55:49 2014
Received: from localhost ([127.0.0.1]:59576 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjYua-0003vU-Ht
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 14:55:49 -0400
Received: from mail-ob0-f175.google.com ([209.85.214.175]:61631)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjYuW-0003vB-JO
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 14:55:46 -0400
Received: by mail-ob0-f175.google.com with SMTP id wo20so7158651obc.6
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 11:55:38 -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=e99LJ1l15aTjyf2g5vz59uoWxoSQH34Mvdf/+7TbX4g=;
 b=c57nCcVwlFAgRmdTpJL8LDicdg4iE2aM9mBMZXCiqYKq8Gn5XTIS6FfTGXFMoQbfQe
 zv7mVht0HDk08+LUNQH204reVf+gFFm01sxtEKG3d5DfPv6c0Ci6TKnV8GMcPlxzfpvp
 tR93mEOYM3vXagPT/I1vTHtVWjG2aasTtcxsGrmv3P07pQm9Go3EP0sBJNNGpVKD6/Ku
 U5m37qKUh+/lmoh3MDgjWeX+RCZcQrZ6SBK6ECvMCq8KT2v69YxhtZ5fD/BjkT0wR+wR
 C+UjIZgKIPDdjJMG7XNXd0/hOzVq9QcVJWvq/Bnlybd7f7oJ155l1vsVpfWYXdLX9k/9
 uIDA==
X-Received: by 10.60.15.38 with SMTP id u6mr28393708oec.26.1399834538486; Sun,
 11 May 2014 11:55:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 11:55:18 -0700 (PDT)
In-Reply-To: <831tw0uqyp.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <8361lcuu1f.fsf@HIDDEN>
 <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
 <8338ggus2g.fsf@HIDDEN>
 <CAHD9_tTj9ydkhf+XFWCphq=RLfGiwnxbECJx1noqsNUxTcyyvQ@HIDDEN>
 <831tw0uqyp.fsf@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 11:55:18 -0700
X-Google-Sender-Auth: nvGXDL9KG_3t6BsadAKHQnhwe1o
Message-ID: <CAHD9_tQ_m7bVtWJ5GJvkUH2=J1ZX0mZZmHOaRAh9o6FfPfN+Aw@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=089e013cc0246932a904f9246087
X-Spam-Score: 0.4 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.4 (/)

--089e013cc0246932a904f9246087
Content-Type: text/plain; charset=UTF-8

Yes, this makes sense. Here is a patch that the issues you mentioned.

(locate-library "tramp.el.gz")
(locate-library "tramp.el")
(locate-library "tramp")

all are working as expected

# Bazaar merge directive format 2 (Bazaar 0.90)
# revision_id: alex@HIDDEN
# target_branch: :parent
# testament_sha1: 66b596e6da58c1cb71dedd7fa9ba2fcf20e2964c
# timestamp: 2014-05-11 11:48:22 -0700
# base_revision_id: monnier@HIDDEN\
#   1mzcrftziwhrw9hl
#
# Begin patch
=== modified file 'lisp/subr.el'
--- lisp/subr.el        2014-04-09 01:48:07 +0000
+++ lisp/subr.el        2014-05-11 18:48:13 +0000
@@ -1857,10 +1857,13 @@
                                        load-path (get-load-suffixes)))
                     nil nil
                     t))
-  (let ((file (locate-file library
-                          (or path load-path)
-                          (append (unless nosuffix (get-load-suffixes))
-                                  load-file-rep-suffixes))))
+  (let ((file
+         (locate-file library
+                      (or path load-path)
+                      (unless (or nosuffix (string-suffix-p ".el.gz"
library))
+                        (if (string-suffix-p ".el" library)
+                            load-file-rep-suffixes
+                          (get-load-suffixes))))))
     (if interactive-call
        (if file
            (message "Library is file %s" (abbreviate-file-name file))

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY0CiMKQlpoOTFBWSZTWYwVAfIAAv3/gDIwFUBQY//3
cwgAAL////BQBZY8tZs1llc7udAaowkqTTQZAM0gBoxAaaAAAJKajTEap+ijaR6I0AA0AAACRTQk
2iTTyJiTTR6j0jJoNAyYgHMAAAAAAAAAABUogmgJgmJiGmpkm0j1MIaAyTLbLDZxNRGLHnrLAyW9
r/aHw7fgG/B1bYJK8emKqTIKmSSJCycvA8sP7hSOWceg7jgMYw8fyi0yw11PqgkQRnWDExNp4bj8
RqO+pIz8yQ2Fww34eP+zJEGZqnl4bjuROkkiD4Ps7JHW+xjfE2vX85EqNzn/x57Z2nVtP9DoxN6P
Dx6uqxRre9Oq+7Y/xotaU8c1dRpQ6+5KWepxa8+ita+XW4lFLHOLnZNgjZOOdrqoLX0kJBMRZUNh
SPeX3UE4RGEyH9RCEE88XW3iMhYSKhgywGRWVrOSpZC37Qy9RhZCYmLzLgVCpqg1zy5r55azmFoF
9mLE1MZFiWq2u1nfQ0/XIm9OebVuTe48Jgal/BGZspfft7pfRpNz1qmChGCYGXkuXN2wpuNGMkp5
sDLMNpfcDpmwpCrjabGLxRHsWsmWnMvxIVR8k2VMoi7Vd0d4gYjGK1bd4IxiQpzAzHBfUTypURs6
AyNExSsr5mphmGZbkw0tYmDK1XsZbIcc7PlcbcJpzYI0nKtLUaGj2Ymdxb+C4CkZk+YRlaGQ6Zlr
lvpPcUMal5eLIhgDg2rIFXMLm1X0maHF1M9uiOYk5GA8CNBQkbKUl3OoQxewiAoDhV31WkywYsmX
tqFRr5EahVsWkK641lETqtGlOo9OqcEmaQoc1DQnY/y9E913ZerM80YJVYzrGVS9eqLlUovUtMUl
+JRpbHzODoye/fSlaLFHk+zW9UOJ7mVhSiGx+UoNJiaSaD5cIDPgh65gbJdO02V4bYqLt4mjQ2yV
N7gptiiqlf6eHa7WDQjzzosjlN8bKBHAQ/RERDRV9VYo5xQD6PwtQjOBAS0nWYG3G0pR/YEUSfc1
kwhj7CTKQ2GiuILRIo3AqVyGQuxwaY7dCqiMrIimZDyQt7KlhiNdhXwhaIkZVi0docU1mcuhkZ9x
KB7TiW1Kw5FC5Lr9wYbjidMEz8fnmTez3Vezk8RfdjclHhu/lYcE2HvSkl3dwczZ3vYsU2uZTmyC
pGCWvoxbFZxnDbiWK3R0F0VCmwaytPBnFWzFgJUHGY1GknHUEbBFk9XGUWvWGR5+nNydadRj5T5z
SnowbUU3afKKana/CUVL2vob4WG74SaMjF3Na1sH1PgNL0cJofdSTEu0o80cZsdsmpxk7pO8pDIM
io8ZPZ31VyN/3Y0OPNR8lnc8X3uvYVaHQNaGlKqxkd7SclywzFyp1l9wyLlklikzNRgWl7YmZFhi
qlE45zGmiSvR+fEjEPBrF82OsnFmkj2sT8NrVpYmr2TM27xjE6wFxhtqWFuEUb7RYB7BMIShLUFE
ZcHNnN0x+WDJCbytnYuXWukzWKFC1sUKSJLFaW3eWAZVe1p6CZcKqW44HeMqWXK1L8WfaquSxY+R
2LJVoYHitMnNlMJMaKKVWVTsc50S9NdIfFFr4mDau6p8kyptF8zTp3pnTC1eoUQpFEvkXI/dHRPP
Vt6zGnryeP4u5IpwoSEYKgPk



On Sun, May 11, 2014 at 11:10 AM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Alex Kosorukoff <alex@HIDDEN>
> > Date: Sun, 11 May 2014 10:53:34 -0700
> > Cc: 17467 <at> debbugs.gnu.org
> >
> > did you mean the following
> >
> > (locate-library "tramp.el") returning the path to tramp.el.gz?
>
> Yes.  But also (locate-library "tramp.el") being able to find
> tramp.el.
>

--089e013cc0246932a904f9246087
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Yes, this makes sense. Here is a patch that the issues you=
 mentioned.<div><br></div><div><div>(locate-library &quot;tramp.el.gz&quot;=
)</div><div>(locate-library &quot;tramp.el&quot;)</div><div>(locate-library=
 &quot;tramp&quot;)</div>

<div><br></div><div style>all are working as expected</div><div><br></div><=
div><div># Bazaar merge directive format 2 (Bazaar 0.90)</div><div># revisi=
on_id: alex@HIDDEN</div><div># target_br=
anch: :parent</div>

<div># testament_sha1: 66b596e6da58c1cb71dedd7fa9ba2fcf20e2964c</div><div>#=
 timestamp: 2014-05-11 11:48:22 -0700</div><div># base_revision_id: monnier=
@iro.umontreal.ca-20140511034953-\</div><div># =C2=A0 1mzcrftziwhrw9hl</div=
>

<div>#=C2=A0</div><div># Begin patch</div><div>=3D=3D=3D modified file &#39=
;lisp/subr.el&#39;</div><div>--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A020=
14-04-09 01:48:07 +0000</div><div>+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=
=A02014-05-11 18:48:13 +0000</div><div>@@ -1857,10 +1857,13 @@</div>

<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 load-=
path (get-load-suffixes)))</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nil nil</div><div>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t))</div><div>- =
=C2=A0(let ((file (locate-file library</div><div>- =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or path =
load-path)</div>

<div>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0(append (unless nosuffix (get-load-suffixes))</div>=
<div>- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load-file-rep-suffixes)=
)))</div><div>+ =C2=A0(let ((file</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (=
locate-file library</div>

<div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(or path load-path)</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(unless (or nosuffix (string-s=
uffix-p &quot;.el.gz&quot; library))</div><div>+ =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (string-suff=
ix-p &quot;.el&quot; library)</div>

<div>+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load-file-rep-suffixes</div><div>+ =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0(get-load-suffixes))))))</div><div>=C2=A0 =C2=A0 =C2=A0(if intera=
ctive-call</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (if file</div><div>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message &quot;Library is file %s&quot; =
(abbreviate-file-name file))</div>

<div><br></div><div># Begin bundle</div><div>IyBCYXphYXIgcmV2aXNpb24gYnVuZG=
xlIHY0CiMKQlpoOTFBWSZTWYwVAfIAAv3/gDIwFUBQY//3</div><div>cwgAAL////BQBZY8tZ=
s1llc7udAaowkqTTQZAM0gBoxAaaAAAJKajTEap+ijaR6I0AA0AAACRTQk</div><div>2iTTyJ=
iTTR6j0jJoNAyYgHMAAAAAAAAAABUogmgJgmJiGmpkm0j1MIaAyTLbLDZxNRGLHnrLAyW9</div=
>

<div>r/aHw7fgG/B1bYJK8emKqTIKmSSJCycvA8sP7hSOWceg7jgMYw8fyi0yw11PqgkQRnWDEx=
Np4bj8</div><div>RqO+pIz8yQ2Fww34eP+zJEGZqnl4bjuROkkiD4Ps7JHW+xjfE2vX85EqNz=
n/x57Z2nVtP9DoxN6P</div><div>Dx6uqxRre9Oq+7Y/xotaU8c1dRpQ6+5KWepxa8+ita+XW4=
lFLHOLnZNgjZOOdrqoLX0kJBMRZUNh</div>

<div>SPeX3UE4RGEyH9RCEE88XW3iMhYSKhgywGRWVrOSpZC37Qy9RhZCYmLzLgVCpqg1zy5r55=
azmFoF</div><div>9mLE1MZFiWq2u1nfQ0/XIm9OebVuTe48Jgal/BGZspfft7pfRpNz1qmChG=
CYGXkuXN2wpuNGMkp5</div><div>sDLMNpfcDpmwpCrjabGLxRHsWsmWnMvxIVR8k2VMoi7Vd0=
d4gYjGK1bd4IxiQpzAzHBfUTypURs6</div>

<div>AyNExSsr5mphmGZbkw0tYmDK1XsZbIcc7PlcbcJpzYI0nKtLUaGj2Ymdxb+C4CkZk+YRla=
GQ6Zlr</div><div>lvpPcUMal5eLIhgDg2rIFXMLm1X0maHF1M9uiOYk5GA8CNBQkbKUl3OoQx=
ewiAoDhV31WkywYsmX</div><div>tqFRr5EahVsWkK641lETqtGlOo9OqcEmaQoc1DQnY/y9E9=
13ZerM80YJVYzrGVS9eqLlUovUtMUl</div>

<div>+JRpbHzODoye/fSlaLFHk+zW9UOJ7mVhSiGx+UoNJiaSaD5cIDPgh65gbJdO02V4bYqLt4=
mjQ2yV</div><div>N7gptiiqlf6eHa7WDQjzzosjlN8bKBHAQ/RERDRV9VYo5xQD6PwtQjOBAS=
0nWYG3G0pR/YEUSfc1</div><div>kwhj7CTKQ2GiuILRIo3AqVyGQuxwaY7dCqiMrIimZDyQt7=
KlhiNdhXwhaIkZVi0docU1mcuhkZ9x</div>

<div>KB7TiW1Kw5FC5Lr9wYbjidMEz8fnmTez3Vezk8RfdjclHhu/lYcE2HvSkl3dwczZ3vYsU2=
uZTmyC</div><div>pGCWvoxbFZxnDbiWK3R0F0VCmwaytPBnFWzFgJUHGY1GknHUEbBFk9XGUW=
vWGR5+nNydadRj5T5z</div><div>SnowbUU3afKKana/CUVL2vob4WG74SaMjF3Na1sH1PgNL0=
cJofdSTEu0o80cZsdsmpxk7pO8pDIM</div>

<div>io8ZPZ31VyN/3Y0OPNR8lnc8X3uvYVaHQNaGlKqxkd7SclywzFyp1l9wyLlklikzNRgWl7=
YmZFhi</div><div>qlE45zGmiSvR+fEjEPBrF82OsnFmkj2sT8NrVpYmr2TM27xjE6wFxhtqWF=
uEUb7RYB7BMIShLUFE</div><div>ZcHNnN0x+WDJCbytnYuXWukzWKFC1sUKSJLFaW3eWAZVe1=
p6CZcKqW44HeMqWXK1L8WfaquSxY+R</div>

<div>2LJVoYHitMnNlMJMaKKVWVTsc50S9NdIfFFr4mDau6p8kyptF8zTp3pnTC1eoUQpFEvkXI=
/dHRPP</div><div>Vt6zGnryeP4u5IpwoSEYKgPk</div></div><div><br></div></div><=
/div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, =
May 11, 2014 at 11:10 AM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">&gt; From: Alex Kosorukoff &lt;<a href=3D"ma=
ilto:alex@HIDDEN">alex@HIDDEN</a>&gt;<br>
&gt; Date: Sun, 11 May 2014 10:53:34 -0700<br>
&gt; Cc: <a href=3D"mailto:17467 <at> debbugs.gnu.org">17467 <at> debbugs.gnu.org</a>=
<br>
<div class=3D"">&gt;<br>
&gt; did you mean the following<br>
&gt;<br>
&gt; (locate-library &quot;tramp.el&quot;) returning the path to tramp.el.g=
z?<br>
<br>
</div>Yes. =C2=A0But also (locate-library &quot;tramp.el&quot;) being able =
to find<br>
tramp.el.<br>
</blockquote></div><br></div>

--089e013cc0246932a904f9246087--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 18:10:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 14:10:29 2014
Received: from localhost ([127.0.0.1]:59531 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjYCi-0002ai-Of
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 14:10:29 -0400
Received: from mtaout20.012.net.il ([80.179.55.166]:56735)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1WjYCd-0002aR-S4
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 14:10:26 -0400
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0N5F00D008UQGN00@HIDDEN> for 17467 <at> debbugs.gnu.org;
 Sun, 11 May 2014 21:10:17 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0N5F00D6J9559950@HIDDEN>;
 Sun, 11 May 2014 21:10:17 +0300 (IDT)
Date: Sun, 11 May 2014 21:10:06 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
In-reply-to: <CAHD9_tTj9ydkhf+XFWCphq=RLfGiwnxbECJx1noqsNUxTcyyvQ@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Alex Kosorukoff <alex@HIDDEN>
Message-id: <831tw0uqyp.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <8361lcuu1f.fsf@HIDDEN>
 <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
 <8338ggus2g.fsf@HIDDEN>
 <CAHD9_tTj9ydkhf+XFWCphq=RLfGiwnxbECJx1noqsNUxTcyyvQ@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> From: Alex Kosorukoff <alex@HIDDEN>
> Date: Sun, 11 May 2014 10:53:34 -0700
> Cc: 17467 <at> debbugs.gnu.org
> 
> did you mean the following
> 
> (locate-library "tramp.el") returning the path to tramp.el.gz?

Yes.  But also (locate-library "tramp.el") being able to find
tramp.el.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:54:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 13:54:06 2014
Received: from localhost ([127.0.0.1]:59523 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjXwp-00028I-HW
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 13:54:05 -0400
Received: from mail-ob0-f178.google.com ([209.85.214.178]:60616)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjXwm-00027j-IA
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 13:54:01 -0400
Received: by mail-ob0-f178.google.com with SMTP id va2so7178668obc.9
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 10:53:54 -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=wqJ39VLkppOI0PrTnxwGJY98KVY+ic+7V4gcjE5hNqw=;
 b=Q3HRRKDbWxpAtmmJyuyzOnHNfdv4OdeY3MfdxzkonM4djB8djPrBHo8DZpw0F4yjyi
 lKlQ1OWF7WeETBOSwNaYZ+PZqZlO1HtzlgJ/tY9abyjFWagYmEwW8jF0m4oQxpLnRjzf
 EzEhD9+nKA5L76FGHPkzVmpoGIyRGWz+w6QXoaNRm5pxleOY4qy8UEQam0PPKvF2cJ0a
 guqd/v/+STg7WYrkl5uqe48TsGjm30UhQnMUUMhbljvW420xI3G3qpiLt1mduSf/gRk1
 813ITV2KGizUwYEU3b1mvHfR1wqyaTGkJqV5yRbz2OR1CA+FhcqHJmSsp304j/LsHHji
 cDpQ==
X-Received: by 10.60.174.164 with SMTP id bt4mr28330817oec.54.1399830834839;
 Sun, 11 May 2014 10:53:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 10:53:34 -0700 (PDT)
In-Reply-To: <8338ggus2g.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <8361lcuu1f.fsf@HIDDEN>
 <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
 <8338ggus2g.fsf@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 10:53:34 -0700
X-Google-Sender-Auth: 9ZJcQL6T9bFvk1E68z8ywYWadEc
Message-ID: <CAHD9_tTj9ydkhf+XFWCphq=RLfGiwnxbECJx1noqsNUxTcyyvQ@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=047d7bd76950a8093504f92383de
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--047d7bd76950a8093504f92383de
Content-Type: text/plain; charset=UTF-8

I am not sure what use case did you mean exactly.

(locate-library "tramp.el.gz" 'nosuffix)  will return the path to
tramp.el.gz as expected

did you mean the following

(locate-library "tramp.el") returning the path to tramp.el.gz?


On Sun, May 11, 2014 at 10:46 AM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Alex Kosorukoff <alex@HIDDEN>
> > Date: Sun, 11 May 2014 10:38:39 -0700
> > Cc: 17467 <at> debbugs.gnu.org
> >
> > I think locate-library has an extra parameter nosuffix, so
> (locate-library
> > "tramp.el" 'nosuffix) will find "tramp.el." I guess for backward
> > compatibility we can set nosuffix to t whenever the name has a valid
> suffix
> > already.
>
> But what about adding ".gz" to it?
>
> In any case, it is very convenient to not have to worry whether
> there's already a suffix there.  You cannot always know that when user
> input is involved.
>

--047d7bd76950a8093504f92383de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div style>I am not sure what use case did you mean exactl=
y.</div><div><br></div><div>(locate-library &quot;tramp.el.gz&quot; &#39;no=
suffix) =C2=A0will return the path to tramp.el.gz as expected<br></div><div=
><br>

</div><div style>did you mean the following</div><div style><br></div><div =
style>(locate-library &quot;tramp.el&quot;) returning the path to tramp.el.=
gz?</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote=
">

On Sun, May 11, 2014 at 10:46 AM, Eli Zaretskii <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wr=
ote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border=
-left:1px #ccc solid;padding-left:1ex">

&gt; From: Alex Kosorukoff &lt;<a href=3D"mailto:alex@HIDDEN">alex@3form=
.com</a>&gt;<br>
&gt; Date: Sun, 11 May 2014 10:38:39 -0700<br>
&gt; Cc: <a href=3D"mailto:17467 <at> debbugs.gnu.org">17467 <at> debbugs.gnu.org</a>=
<br>
<div class=3D"">&gt;<br>
&gt; I think locate-library has an extra parameter nosuffix, so (locate-lib=
rary<br>
&gt; &quot;tramp.el&quot; &#39;nosuffix) will find &quot;tramp.el.&quot; I =
guess for backward<br>
&gt; compatibility we can set nosuffix to t whenever the name has a valid s=
uffix<br>
&gt; already.<br>
<br>
</div>But what about adding &quot;.gz&quot; to it?<br>
<br>
In any case, it is very convenient to not have to worry whether<br>
there&#39;s already a suffix there. =C2=A0You cannot always know that when =
user<br>
input is involved.<br>
</blockquote></div><br></div>

--047d7bd76950a8093504f92383de--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:46:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 13:46:36 2014
Received: from localhost ([127.0.0.1]:59516 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjXpb-0001vZ-5Z
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 13:46:35 -0400
Received: from mtaout20.012.net.il ([80.179.55.166]:52849)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1WjXpZ-0001vG-AU
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 13:46:34 -0400
Received: from conversion-daemon.a-mtaout20.012.net.il by
 a-mtaout20.012.net.il (HyperSendmail v2007.08) id
 <0N5F00D007V4A500@HIDDEN> for 17467 <at> debbugs.gnu.org;
 Sun, 11 May 2014 20:46:27 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0N5F00D4B81E9920@HIDDEN>;
 Sun, 11 May 2014 20:46:27 +0300 (IDT)
Date: Sun, 11 May 2014 20:46:15 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
In-reply-to: <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Alex Kosorukoff <alex@HIDDEN>
Message-id: <8338ggus2g.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <8361lcuu1f.fsf@HIDDEN>
 <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> From: Alex Kosorukoff <alex@HIDDEN>
> Date: Sun, 11 May 2014 10:38:39 -0700
> Cc: 17467 <at> debbugs.gnu.org
> 
> I think locate-library has an extra parameter nosuffix, so (locate-library
> "tramp.el" 'nosuffix) will find "tramp.el." I guess for backward
> compatibility we can set nosuffix to t whenever the name has a valid suffix
> already.

But what about adding ".gz" to it?

In any case, it is very convenient to not have to worry whether
there's already a suffix there.  You cannot always know that when user
input is involved.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:43:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 13:43:37 2014
Received: from localhost ([127.0.0.1]:59511 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjXmj-0001q5-DP
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 13:43:37 -0400
Received: from mail-ob0-f173.google.com ([209.85.214.173]:50677)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjXmh-0001pr-2n
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 13:43:35 -0400
Received: by mail-ob0-f173.google.com with SMTP id wm4so7052437obc.4
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 10:43:29 -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=p2YNnYP3lmDzzMtOeGySWQDtKuBp9H3F6xrNPZuuWfI=;
 b=tL+wgWH15ZzdFEZzHGCKPBQJ0gHyjIl2/19FS0r8uB6kubZZfUqMveLMTaXh2zscdf
 +mTEOEO8eTy5jwMuQG+x/72wuUq9oa+7V0HrSY4LbsO5Xsfrp0enz9hdb7izE4UftMrE
 AlBFkrRk2L3tA5ZdiGGki2SlUNL41YmPA4ycotG8ZkwXmY+ePCmLnU7eIyLDCnSW9EdU
 Yk1rM6B7w82E2Gj+PqkHZTcgiU9Ti/ozjCHgRg2wW7XUVuulWdgdZ6Jcv2k7q7FnC0NE
 N1ejqT9UU2n05TCZT1xOiuaPQroX8+Ar3QHqd7UhwNpoybpDMCmgci7DTmgZLh7Ag4sr
 VKMw==
X-Received: by 10.182.43.132 with SMTP id w4mr28215204obl.41.1399830209299;
 Sun, 11 May 2014 10:43:29 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 10:43:09 -0700 (PDT)
In-Reply-To: <ngtx8w6wtz.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <ngtx8w6wtz.fsf@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 10:43:09 -0700
X-Google-Sender-Auth: enZzo-Aqlv6xl9WgKR54bZU2FPA
Message-ID: <CAHD9_tQconD1CJWY7FZ5ht9hrXMnT_1VhaoQQhG9rQbmYwdcDA@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Glenn Morris <rgm@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c303a25f0c3204f9235ef1
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <17467 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c303a25f0c3204f9235ef1
Content-Type: text/plain; charset=UTF-8

You are right, I had my ~/.emacs.d in the load-path. I removed it as my
first step to resolve this issue, but then I thought that even if it were
in the load-path, returning the path to a file without a valid library
extension is an unexpected behavior for locate-library.


On Sun, May 11, 2014 at 10:37 AM, Glenn Morris <rgm@HIDDEN> wrote:

> Alex Kosorukoff wrote:
>
> > I found this issue because (locate-library "tramp") was returning
> > "/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc".
>
> I assume there are some typos there...
>
> Anyway, sounds like you have your ~/.emacs.d directory in load-path?
> You are strongly encouraged not to do that.
> Newer Emacs will in fact warn you about it.
> Because you can get problems just like this one! :)
>

--001a11c303a25f0c3204f9235ef1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You are right, I had my ~/.emacs.d in the load-path. I rem=
oved it as my first step to resolve this issue, but then I thought that eve=
n if it were in the load-path, returning the path to a file without a valid=
 library extension is an unexpected behavior for locate-library.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, May 1=
1, 2014 at 10:37 AM, Glenn Morris <span dir=3D"ltr">&lt;<a href=3D"mailto:r=
gm@HIDDEN" target=3D"_blank">rgm@HIDDEN</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">

<div class=3D"">Alex Kosorukoff wrote:<br>
<br>
&gt; I found this issue because (locate-library &quot;tramp&quot;) was retu=
rning<br>
&gt; &quot;/home/alex/.emacs.d/trump&quot; not &quot;../lisp/net/trum.elc&q=
uot;.<br>
<br>
</div>I assume there are some typos there...<br>
<br>
Anyway, sounds like you have your ~/.emacs.d directory in load-path?<br>
You are strongly encouraged not to do that.<br>
Newer Emacs will in fact warn you about it.<br>
Because you can get problems just like this one! :)<br>
</blockquote></div><br></div>

--001a11c303a25f0c3204f9235ef1--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:39:08 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 13:39:08 2014
Received: from localhost ([127.0.0.1]:59499 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjXiN-0001iK-DT
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 13:39:07 -0400
Received: from mail-ob0-f178.google.com ([209.85.214.178]:45517)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjXiL-0001hn-KN
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 13:39:06 -0400
Received: by mail-ob0-f178.google.com with SMTP id va2so7170475obc.9
 for <17467 <at> debbugs.gnu.org>; Sun, 11 May 2014 10:39:00 -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=qwctl9hFBsC+JUYkjvUTYsXHLmIO83HqNUdoinRkNmQ=;
 b=tkTx5BQIldFh1BsCmmp8H7kJc9WI1596z37ZrxS2doTW99J4iW401PeZ7fMgGp/J77
 vO/0Q2AFLLIz0MjQdFRaLh+zy82ERysJPgZcNVHweJOIcOaeI761XRysrBUeNkOSCxCS
 TgwTw0A+CcnGbKwmxzIfdXoOIkAe0FsT8keHK3LiyHrQ4GBRSbylyP1GNg8McnW+wbu/
 NbCxI+x9zIGAwPVQFblhrd+3pqHXQFQPjhp0BFkVAWW9dvjQ8LQYHNnbpWSiIW1++XJL
 F1GhfYu6rYMlPVo/RzQMYYy2MuIWPSlu5QYI3UYymZb6yuzN6MSMNnLDsgq1nXvzhh1E
 PpCA==
X-Received: by 10.182.18.102 with SMTP id v6mr2972791obd.71.1399829939936;
 Sun, 11 May 2014 10:38:59 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 10:38:39 -0700 (PDT)
In-Reply-To: <8361lcuu1f.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 <8361lcuu1f.fsf@HIDDEN>
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 10:38:39 -0700
X-Google-Sender-Auth: PPn_ZA2n7OE5J7rRVqqq6LS6xq0
Message-ID: <CAHD9_tSansrsN9ToS4FL1bBe3kdnaQMLUTy=fZp+BiDA7R9tRg@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
To: Eli Zaretskii <eliz@HIDDEN>
Content-Type: multipart/alternative; boundary=001a11c339e650e56704f9234e2e
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

--001a11c339e650e56704f9234e2e
Content-Type: text/plain; charset=UTF-8

I think locate-library has an extra parameter nosuffix, so (locate-library
"tramp.el" 'nosuffix) will find "tramp.el." I guess for backward
compatibility we can set nosuffix to t whenever the name has a valid suffix
already.


On Sun, May 11, 2014 at 10:03 AM, Eli Zaretskii <eliz@HIDDEN> wrote:

> > From: Alex Kosorukoff <alex@HIDDEN>
> > Date: Sun, 11 May 2014 09:06:10 -0700
> >
> > 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. 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))
>
> What if I say
>
>   (locate-library "tramp.el")
>
> Shouldn't it be able to find tramp.el.gz then?
>

--001a11c339e650e56704f9234e2e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think locate-library has an extra parameter nosuffix, so=
 (locate-library &quot;tramp.el&quot; &#39;nosuffix) will find &quot;tramp.=
el.&quot; I guess for backward compatibility we can set nosuffix to t whene=
ver the name has a valid suffix already.</div>

<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun, May 1=
1, 2014 at 10:03 AM, Eli Zaretskii <span dir=3D"ltr">&lt;<a href=3D"mailto:=
eliz@HIDDEN" target=3D"_blank">eliz@HIDDEN</a>&gt;</span> wrote:<br><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #cc=
c solid;padding-left:1ex">

&gt; From: Alex Kosorukoff &lt;<a href=3D"mailto:alex@HIDDEN">alex@3form=
.com</a>&gt;<br>
&gt; Date: Sun, 11 May 2014 09:06:10 -0700<br>
&gt;<br>
&gt; locate-library incorrectly generates a set of suffixes to extend the<b=
r>
&gt; base library name (&quot;.elc&quot; &quot;.elc.gz&quot; &quot;.el&quot=
; &quot;.el.gz&quot; &quot;&quot; &quot;.gz&quot;), while it<br>
&gt; should be just (&quot;.elc&quot; &quot;.elc.gz&quot; &quot;.el&quot; &=
quot;.el.gz&quot;) when nosuffix is<br>
&gt; nil. This leads to spurious paths found, like name.gz. I found<br>
&gt; this issue because (locate-library &quot;tramp&quot;) was returning<br=
>
&gt; &quot;/home/alex/.emacs.d/trump&quot; not &quot;../lisp/net/trum.elc&q=
uot;. The workaround<br>
&gt; is (locate-file &quot;tramp&quot; load-path (get-load-suffixes))<br>
<br>
What if I say<br>
<br>
=C2=A0 (locate-library &quot;tramp.el&quot;)<br>
<br>
Shouldn&#39;t it be able to find tramp.el.gz then?<br>
</blockquote></div><br></div>

--001a11c339e650e56704f9234e2e--




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:37:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 13:37:18 2014
Received: from localhost ([127.0.0.1]:59492 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjXgb-0001f1-Ld
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 13:37:17 -0400
Received: from fencepost.gnu.org ([208.118.235.10]:48993 ident=Debian-exim)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <rgm@HIDDEN>) id 1WjXgY-0001es-Rp
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 13:37:15 -0400
Received: from rgm by fencepost.gnu.org with local (Exim 4.71)
 (envelope-from <rgm@HIDDEN>)
 id 1WjXgW-0001mL-W9; Sun, 11 May 2014 13:37:13 -0400
From: Glenn Morris <rgm@HIDDEN>
To: Alex Kosorukoff <alex@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
X-Spook: eavesdropping AVIP Gazprom underground Maple wire
X-Ran: na!B%Sr[VVXhiY'wOM/w3Gzl?F`"dj3`>1}_T7*#H?WSz("nvk*(R/C$YscMel?([-?CRM
X-Hue: white
X-Debbugs-No-Ack: yes
X-Attribution: GM
Date: Sun, 11 May 2014 13:37:12 -0400
In-Reply-To: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
 (Alex Kosorukoff's message of "Sun, 11 May 2014 09:06:10 -0700")
Message-ID: <ngtx8w6wtz.fsf@HIDDEN>
User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Spam-Score: -5.7 (-----)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -5.7 (-----)

Alex Kosorukoff wrote:

> I found this issue because (locate-library "tramp") was returning
> "/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc".

I assume there are some typos there...

Anyway, sounds like you have your ~/.emacs.d directory in load-path?
You are strongly encouraged not to do that.
Newer Emacs will in fact warn you about it.
Because you can get problems just like this one! :)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at 17467 <at> debbugs.gnu.org:


Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:04:01 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 13:04:01 2014
Received: from localhost ([127.0.0.1]:59473 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjXAO-000844-Qu
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 13:04:01 -0400
Received: from mtaout28.012.net.il ([80.179.55.184]:52099)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <eliz@HIDDEN>) id 1WjXAM-00083k-6n
 for 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 13:03:59 -0400
Received: from conversion-daemon.mtaout28.012.net.il by mtaout28.012.net.il
 (HyperSendmail v2007.08) id <0N5F009005IXYW00@HIDDEN> for
 17467 <at> debbugs.gnu.org; Sun, 11 May 2014 20:02:11 +0300 (IDT)
Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout28.012.net.il
 (HyperSendmail v2007.08) with ESMTPA id
 <0N5F007UO5ZM3M40@HIDDEN>; Sun, 11 May 2014 20:02:11 +0300 (IDT)
Date: Sun, 11 May 2014 20:03:40 +0300
From: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#17467: 24.3; locate-library returning spurious path
In-reply-to: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
X-012-Sender: halo1@HIDDEN
To: Alex Kosorukoff <alex@HIDDEN>
Message-id: <8361lcuu1f.fsf@HIDDEN>
References: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 17467
Cc: 17467 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Eli Zaretskii <eliz@HIDDEN>
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)

> From: Alex Kosorukoff <alex@HIDDEN>
> Date: Sun, 11 May 2014 09:06:10 -0700
> 
> 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. 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))

What if I say

  (locate-library "tramp.el")

Shouldn't it be able to find tramp.el.gz then?




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 11 May 2014 16:50:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun May 11 12:50:30 2014
Received: from localhost ([127.0.0.1]:59461 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.80)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1WjWxJ-0007h7-1i
	for submit <at> debbugs.gnu.org; Sun, 11 May 2014 12:50:29 -0400
Received: from eggs.gnu.org ([208.118.235.92]:34308)
 by debbugs.gnu.org with esmtp (Exim 4.80)
 (envelope-from <alexkos@HIDDEN>) id 1WjWGt-0006Vi-Ns
 for submit <at> debbugs.gnu.org; Sun, 11 May 2014 12:06:40 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <alexkos@HIDDEN>) id 1WjWGn-0002KV-RO
 for submit <at> debbugs.gnu.org; Sun, 11 May 2014 12:06:34 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_20,FREEMAIL_FROM,
 HTML_MESSAGE,T_DKIM_INVALID autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:34490)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <alexkos@HIDDEN>) id 1WjWGn-0002KQ-No
 for submit <at> debbugs.gnu.org; Sun, 11 May 2014 12:06:33 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:36008)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <alexkos@HIDDEN>) id 1WjWGm-0005hA-JJ
 for bug-gnu-emacs@HIDDEN; Sun, 11 May 2014 12:06:33 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <alexkos@HIDDEN>) id 1WjWGl-0002Jl-Ie
 for bug-gnu-emacs@HIDDEN; Sun, 11 May 2014 12:06:32 -0400
Received: from mail-oa0-x236.google.com ([2607:f8b0:4003:c02::236]:39793)
 by eggs.gnu.org with esmtp (Exim 4.71)
 (envelope-from <alexkos@HIDDEN>) id 1WjWGl-0002JX-DR
 for bug-gnu-emacs@HIDDEN; Sun, 11 May 2014 12:06:31 -0400
Received: by mail-oa0-f54.google.com with SMTP id j17so7110020oag.41
 for <bug-gnu-emacs@HIDDEN>; Sun, 11 May 2014 09:06:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
 h=mime-version:sender:from:date:message-id:subject:to:content-type;
 bh=+YfGyh2ui+Dbk6K1B+MjcIvm9FJHPekHlWr1ezRQekI=;
 b=HbGVjdRLBt7q4Oy+h/opzxdA/m+b7RhXixP2C0WPzijAQCbn/PwoMMo0giWWZ8Lrwt
 Vf4LEL4FzAuUmqDrcwRl+ZQMZpe4VjQVU4ZxpL08u4yKcsBwWCcUIQM3Q+sm1ygsEFIn
 qT5Nu59pkpmzwm6EkusKXlU03wIssm0bi7Zsi+xQt8mVVRsR8F183XMS1CCGmerZLLfd
 naSZB+z8EcTuCCa9Y5HFWoEM5zM2S/3G0XIRyxW8qkwbq+gitFWeY56b1rghvier1HWk
 l8mlRPqOyGVPC61A6VJW6DIWsdYuB9eNzZzElwSIanoTAVR/4vxpg7YymdmlA7Ugq5Wt
 bTpw==
X-Received: by 10.182.97.97 with SMTP id dz1mr27930270obb.13.1399824390793;
 Sun, 11 May 2014 09:06:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 09:06:10 -0700 (PDT)
From: Alex Kosorukoff <alex@HIDDEN>
Date: Sun, 11 May 2014 09:06:10 -0700
X-Google-Sender-Auth: R1k-cbP0gwYYksue2j0PWqfXofs
Message-ID: <CAHD9_tTGEayPmRyX-D+1C5BQd7PU52nTCYON7E3pfM+aHOsaTg@HIDDEN>
Subject: 24.3; locate-library returning spurious path
To: bug-gnu-emacs@HIDDEN
Content-Type: multipart/alternative; boundary=047d7b2e43868fae4304f92203ce
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address
 (bad octet value).
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.0 (----)
X-Debbugs-Envelope-To: submit
X-Mailman-Approved-At: Sun, 11 May 2014 12:50:22 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.0 (----)

--047d7b2e43868fae4304f92203ce
Content-Type: text/plain; charset=UTF-8

Hello:

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. 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))

Best,
Alex

--047d7b2e43868fae4304f92203ce
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hello:</div><div><br></div><div>locate-library incorr=
ectly generates a set of suffixes to extend the</div><div>base library name=
 (&quot;.elc&quot; &quot;.elc.gz&quot; &quot;.el&quot; &quot;.el.gz&quot; &=
quot;&quot; &quot;.gz&quot;), while it</div>

<div>should be just (&quot;.elc&quot; &quot;.elc.gz&quot; &quot;.el&quot; &=
quot;.el.gz&quot;) when nosuffix is</div><div>nil. This leads to spurious p=
aths found, like name.gz. I found</div><div>this issue because (locate-libr=
ary &quot;tramp&quot;) was returning</div>

<div>&quot;/home/alex/.emacs.d/trump&quot; not &quot;../lisp/net/trum.elc&q=
uot;. The workaround</div><div>is (locate-file &quot;tramp&quot; load-path =
(get-load-suffixes))</div><div><br></div><div>Best,</div><div>Alex</div>

<div><br></div></div>

--047d7b2e43868fae4304f92203ce--




Acknowledgement sent to Alex Kosorukoff <alex@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#17467; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Fri, 31 Oct 2014 17:00:04 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.