From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 12:50:30 2014 Received: (at submit) by debbugs.gnu.org; 11 May 2014 16:50:30 +0000 Received: from localhost ([127.0.0.1]:59461 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjWxJ-0007h7-1i for submit@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 ) id 1WjWGt-0006Vi-Ns for submit@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 ) id 1WjWGn-0002KV-RO for submit@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 ) id 1WjWGn-0002KQ-No for submit@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 ) id 1WjWGm-0005hA-JJ for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 12:06:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjWGl-0002Jl-Ie for bug-gnu-emacs@gnu.org; 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 ) id 1WjWGl-0002JX-DR for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 12:06:31 -0400 Received: by mail-oa0-f54.google.com with SMTP id j17so7110020oag.41 for ; 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 Date: Sun, 11 May 2014 09:06:10 -0700 X-Google-Sender-Auth: R1k-cbP0gwYYksue2j0PWqfXofs Message-ID: Subject: 24.3; locate-library returning spurious path To: bug-gnu-emacs@gnu.org 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@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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
Hello:

locate-library incorr= ectly generates a set of suffixes to extend the
base library name= (".elc" ".elc.gz" ".el" ".el.gz" &= quot;" ".gz"), while it
should be just (".elc" ".elc.gz" ".el" &= quot;.el.gz") when nosuffix is
nil. This leads to spurious p= aths found, like name.gz. I found
this issue because (locate-libr= ary "tramp") was returning
"/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc&q= uot;. The workaround
is (locate-file "tramp" load-path = (get-load-suffixes))

Best,
Alex

--047d7b2e43868fae4304f92203ce-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 13:04:01 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:04:01 +0000 Received: from localhost ([127.0.0.1]:59473 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjXAO-000844-Qu for submit@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 ) id 1WjXAM-00083k-6n for 17467@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@mtaout28.012.net.il> for 17467@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@mtaout28.012.net.il>; Sun, 11 May 2014 20:02:11 +0300 (IDT) Date: Sun, 11 May 2014 20:03:40 +0300 From: Eli Zaretskii Subject: Re: bug#17467: 24.3; locate-library returning spurious path In-reply-to: X-012-Sender: halo1@inter.net.il To: Alex Kosorukoff Message-id: <8361lcuu1f.fsf@gnu.org> References: X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17467 Cc: 17467@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Alex Kosorukoff > 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? From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 13:37:18 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:37:18 +0000 Received: from localhost ([127.0.0.1]:59492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjXgb-0001f1-Ld for submit@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 ) id 1WjXgY-0001es-Rp for 17467@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 ) id 1WjXgW-0001mL-W9; Sun, 11 May 2014 13:37:13 -0400 From: Glenn Morris To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path References: 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: (Alex Kosorukoff's message of "Sun, 11 May 2014 09:06:10 -0700") Message-ID: 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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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! :) From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 13:39:08 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:39:08 +0000 Received: from localhost ([127.0.0.1]:59499 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjXiN-0001iK-DT for submit@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 ) id 1WjXiL-0001hn-KN for 17467@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@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@gnu.org> References: <8361lcuu1f.fsf@gnu.org> From: Alex Kosorukoff Date: Sun, 11 May 2014 10:38:39 -0700 X-Google-Sender-Auth: PPn_ZA2n7OE5J7rRVqqq6LS6xq0 Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Eli Zaretskii Content-Type: multipart/alternative; boundary=001a11c339e650e56704f9234e2e X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 wrote: > > From: Alex Kosorukoff > > 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
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 whene= ver the name has a valid suffix already.


On Sun, May 1= 1, 2014 at 10:03 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Alex Kosorukoff <alex@3form= .com>
> 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" &= quot;.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&q= uot;. The workaround
> is (locate-file "tramp" load-path (get-load-suffixes))

What if I say

=C2=A0 (locate-library "tramp.el")

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

--001a11c339e650e56704f9234e2e-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 13:43:37 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:43:38 +0000 Received: from localhost ([127.0.0.1]:59511 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjXmj-0001q5-DP for submit@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 ) id 1WjXmh-0001pr-2n for 17467@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@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: References: From: Alex Kosorukoff Date: Sun, 11 May 2014 10:43:09 -0700 X-Google-Sender-Auth: enZzo-Aqlv6xl9WgKR54bZU2FPA Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Glenn Morris Content-Type: multipart/alternative; boundary=001a11c303a25f0c3204f9235ef1 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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
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.


On Sun, May 1= 1, 2014 at 10:37 AM, Glenn Morris <rgm@gnu.org> wrote:
Alex Kosorukoff wrote:

> I found this issue because (locate-library "tramp") was retu= rning
> "/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc&q= uot;.

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-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 13:46:36 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:46:36 +0000 Received: from localhost ([127.0.0.1]:59516 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjXpb-0001vZ-5Z for submit@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 ) id 1WjXpZ-0001vG-AU for 17467@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@a-mtaout20.012.net.il> for 17467@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@a-mtaout20.012.net.il>; Sun, 11 May 2014 20:46:27 +0300 (IDT) Date: Sun, 11 May 2014 20:46:15 +0300 From: Eli Zaretskii Subject: Re: bug#17467: 24.3; locate-library returning spurious path In-reply-to: X-012-Sender: halo1@inter.net.il To: Alex Kosorukoff Message-id: <8338ggus2g.fsf@gnu.org> References: <8361lcuu1f.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17467 Cc: 17467@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Alex Kosorukoff > Date: Sun, 11 May 2014 10:38:39 -0700 > Cc: 17467@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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 13:54:06 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 17:54:06 +0000 Received: from localhost ([127.0.0.1]:59523 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjXwp-00028I-HW for submit@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 ) id 1WjXwm-00027j-IA for 17467@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@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@gnu.org> References: <8361lcuu1f.fsf@gnu.org> <8338ggus2g.fsf@gnu.org> From: Alex Kosorukoff Date: Sun, 11 May 2014 10:53:34 -0700 X-Google-Sender-Auth: 9ZJcQL6T9bFvk1E68z8ywYWadEc Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Eli Zaretskii Content-Type: multipart/alternative; boundary=047d7bd76950a8093504f92383de X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 wrote: > > From: Alex Kosorukoff > > Date: Sun, 11 May 2014 10:38:39 -0700 > > Cc: 17467@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
I am not sure what use case did you mean exactl= y.

(locate-library "tramp.el.gz" 'no= suffix) =C2=A0will 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@gnu.org> wr= ote:
> From: Alex Kosorukoff <alex@3form= .com>
> Date: Sun, 11 May 2014 10:38:39 -0700
> Cc: 17467@debbugs.gnu.org=
>
> I think locate-library has an extra parameter nosuffix, so (locate-lib= rary
> "tramp.el" 'nosuffix) will find "tramp.el." I = guess for backward
> compatibility we can set nosuffix to t whenever the name has a valid s= uffix
> 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. =C2=A0You cannot always know that when = user
input is involved.

--047d7bd76950a8093504f92383de-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 14:10:29 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 18:10:29 +0000 Received: from localhost ([127.0.0.1]:59531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjYCi-0002ai-Of for submit@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 ) id 1WjYCd-0002aR-S4 for 17467@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@a-mtaout20.012.net.il> for 17467@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@a-mtaout20.012.net.il>; Sun, 11 May 2014 21:10:17 +0300 (IDT) Date: Sun, 11 May 2014 21:10:06 +0300 From: Eli Zaretskii Subject: Re: bug#17467: 24.3; locate-library returning spurious path In-reply-to: X-012-Sender: halo1@inter.net.il To: Alex Kosorukoff Message-id: <831tw0uqyp.fsf@gnu.org> References: <8361lcuu1f.fsf@gnu.org> <8338ggus2g.fsf@gnu.org> X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 17467 Cc: 17467@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) > From: Alex Kosorukoff > Date: Sun, 11 May 2014 10:53:34 -0700 > Cc: 17467@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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 14:55:49 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 18:55:49 +0000 Received: from localhost ([127.0.0.1]:59576 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjYua-0003vU-Ht for submit@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 ) id 1WjYuW-0003vB-JO for 17467@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@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@gnu.org> References: <8361lcuu1f.fsf@gnu.org> <8338ggus2g.fsf@gnu.org> <831tw0uqyp.fsf@gnu.org> From: Alex Kosorukoff Date: Sun, 11 May 2014 11:55:18 -0700 X-Google-Sender-Auth: nvGXDL9KG_3t6BsadAKHQnhwe1o Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Eli Zaretskii Content-Type: multipart/alternative; boundary=089e013cc0246932a904f9246087 X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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@3form.com-20140511184813-t6p0r8ac4em9kuyf # target_branch: :parent # testament_sha1: 66b596e6da58c1cb71dedd7fa9ba2fcf20e2964c # timestamp: 2014-05-11 11:48:22 -0700 # base_revision_id: monnier@iro.umontreal.ca-20140511034953-\ # 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 wrote: > > From: Alex Kosorukoff > > Date: Sun, 11 May 2014 10:53:34 -0700 > > Cc: 17467@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
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

<= div>
# Bazaar merge directive format 2 (Bazaar 0.90)
# revisi= on_id: alex@3form.com-20140511184813-t6p0r8ac4em9kuyf
# target_br= anch: :parent
# testament_sha1: 66b596e6da58c1cb71dedd7fa9ba2fcf20e2964c
#= timestamp: 2014-05-11 11:48:22 -0700
# base_revision_id: monnier= @iro.umontreal.ca-20140511034953-\
# =C2=A0 1mzcrftziwhrw9hl
#=C2=A0
# Begin patch
=3D=3D=3D modified file '= ;lisp/subr.el'
--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A020= 14-04-09 01:48:07 +0000
+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2= =A02014-05-11 18:48:13 +0000
@@ -1857,10 +1857,13 @@
=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)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nil nil
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0t))
- = =C2=A0(let ((file (locate-file library
- =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)
- =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))
=
- =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)= )))
+ =C2=A0(let ((file
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (= locate-file library
+ =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)
+ =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 ".el.gz" library))
+ =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 ".el" library)
+ =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
+ =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))))))
=C2=A0 =C2=A0 =C2=A0(if intera= ctive-call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (if file
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message "Library is file %s" = (abbreviate-file-name file))

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZG= xlIHY0CiMKQlpoOTFBWSZTWYwVAfIAAv3/gDIwFUBQY//3
cwgAAL////BQBZY8tZ= s1llc7udAaowkqTTQZAM0gBoxAaaAAAJKajTEap+ijaR6I0AA0AAACRTQk
2iTTyJ= iTTR6j0jJoNAyYgHMAAAAAAAAAABUogmgJgmJiGmpkm0j1MIaAyTLbLDZxNRGLHnrLAyW9
r/aHw7fgG/B1bYJK8emKqTIKmSSJCycvA8sP7hSOWceg7jgMYw8fyi0yw11PqgkQRnWDEx= Np4bj8
RqO+pIz8yQ2Fww34eP+zJEGZqnl4bjuROkkiD4Ps7JHW+xjfE2vX85EqNz= n/x57Z2nVtP9DoxN6P
Dx6uqxRre9Oq+7Y/xotaU8c1dRpQ6+5KWepxa8+ita+XW4= lFLHOLnZNgjZOOdrqoLX0kJBMRZUNh
SPeX3UE4RGEyH9RCEE88XW3iMhYSKhgywGRWVrOSpZC37Qy9RhZCYmLzLgVCpqg1zy5r55= azmFoF
9mLE1MZFiWq2u1nfQ0/XIm9OebVuTe48Jgal/BGZspfft7pfRpNz1qmChG= CYGXkuXN2wpuNGMkp5
sDLMNpfcDpmwpCrjabGLxRHsWsmWnMvxIVR8k2VMoi7Vd0= d4gYjGK1bd4IxiQpzAzHBfUTypURs6
AyNExSsr5mphmGZbkw0tYmDK1XsZbIcc7PlcbcJpzYI0nKtLUaGj2Ymdxb+C4CkZk+YRla= GQ6Zlr
lvpPcUMal5eLIhgDg2rIFXMLm1X0maHF1M9uiOYk5GA8CNBQkbKUl3OoQx= ewiAoDhV31WkywYsmX
tqFRr5EahVsWkK641lETqtGlOo9OqcEmaQoc1DQnY/y9E9= 13ZerM80YJVYzrGVS9eqLlUovUtMUl
+JRpbHzODoye/fSlaLFHk+zW9UOJ7mVhSiGx+UoNJiaSaD5cIDPgh65gbJdO02V4bYqLt4= mjQ2yV
N7gptiiqlf6eHa7WDQjzzosjlN8bKBHAQ/RERDRV9VYo5xQD6PwtQjOBAS= 0nWYG3G0pR/YEUSfc1
kwhj7CTKQ2GiuILRIo3AqVyGQuxwaY7dCqiMrIimZDyQt7= KlhiNdhXwhaIkZVi0docU1mcuhkZ9x
KB7TiW1Kw5FC5Lr9wYbjidMEz8fnmTez3Vezk8RfdjclHhu/lYcE2HvSkl3dwczZ3vYsU2= uZTmyC
pGCWvoxbFZxnDbiWK3R0F0VCmwaytPBnFWzFgJUHGY1GknHUEbBFk9XGUW= vWGR5+nNydadRj5T5z
SnowbUU3afKKana/CUVL2vob4WG74SaMjF3Na1sH1PgNL0= cJofdSTEu0o80cZsdsmpxk7pO8pDIM
io8ZPZ31VyN/3Y0OPNR8lnc8X3uvYVaHQNaGlKqxkd7SclywzFyp1l9wyLlklikzNRgWl7= YmZFhi
qlE45zGmiSvR+fEjEPBrF82OsnFmkj2sT8NrVpYmr2TM27xjE6wFxhtqWF= uEUb7RYB7BMIShLUFE
ZcHNnN0x+WDJCbytnYuXWukzWKFC1sUKSJLFaW3eWAZVe1= p6CZcKqW44HeMqWXK1L8WfaquSxY+R
2LJVoYHitMnNlMJMaKKVWVTsc50S9NdIfFFr4mDau6p8kyptF8zTp3pnTC1eoUQpFEvkXI= /dHRPP
Vt6zGnryeP4u5IpwoSEYKgPk

<= /div>


On Sun, = May 11, 2014 at 11:10 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> From: Alex Kosorukoff <alex@3form.com>
> Date: Sun, 11 May 2014 10:53:34 -0700
> Cc: 17467@debbugs.gnu.org=
>
> did you mean the following
>
> (locate-library "tramp.el") returning the path to tramp.el.g= z?

Yes. =C2=A0But also (locate-library "tramp.el") being able = to find
tramp.el.

--089e013cc0246932a904f9246087-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 15:50:25 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 19:50:25 +0000 Received: from localhost ([127.0.0.1]:59662 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjZlQ-0005Wr-LE for submit@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 ) id 1WjZlN-0005WV-Js for 17467@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 To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path Message-ID: References: Date: Sun, 11 May 2014 15:50:15 -0400 In-Reply-To: (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@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 16:45:43 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 20:45:43 +0000 Received: from localhost ([127.0.0.1]:59721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjacw-000745-7M for submit@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 ) id 1Wjacs-00073n-U8 for 17467@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@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: References: From: Alex Kosorukoff Date: Sun, 11 May 2014 13:45:12 -0700 X-Google-Sender-Auth: 4wpv_lDMvdUna5y-rGHh8iw4Rxo Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Stefan Monnier Content-Type: multipart/alternative; boundary=089e0149cc30786b1704f925e9f8 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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
The issue is that locate-library returns spurio= us 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. I= t can cause user inconvenience or pose a security/privacy issue because a r= andom file named "tramp" or "tramp.gz" 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.

= On Sun, May 11, 2014 at 12:50 PM, Stefan Monnier <monnier@iro.umont= real.ca> wrote:
> it should be just (".elc" &= quot;.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&= #39;d
prefer that behavior? =C2=A0Which concrete cases do you specifically care a= bout?

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

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. =C2=A0Maybe we can accommodate your specific concrete cases in some other way.

I understand that the b= ug was there for many years and many people=C2=A0implemented 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 f= ixing it. Unit tests can help.
=C2=A0


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

--089e0149cc30786b1704f925e9f8-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 17:01:19 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 21:01:19 +0000 Received: from localhost ([127.0.0.1]:59737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjas1-0007VZ-Sx for submit@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 ) id 1Wjary-0007VK-O5 for 17467@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@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: References: From: Alex Kosorukoff Date: Sun, 11 May 2014 14:00:48 -0700 X-Google-Sender-Auth: MORjKJOzzDlhJdYJPJjrpPC99rk Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Stefan Monnier Content-Type: multipart/alternative; boundary=e89a8f502d04429a1204f9262149 X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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@3form.com-20140511205538-1asyz50g7d3y4lgw # target_branch: :parent # testament_sha1: d9ca6f57d0d8486d42ed77a739877a208a34f22e # timestamp: 2014-05-11 13:55:53 -0700 # base_revision_id: monnier@iro.umontreal.ca-20140511034953-\ # 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 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 > 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
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_i= d: alex@3form.com-20140511205538-1asyz50g7d3y4lgw
# target_branch= : :parent
# testament_sha1: d9ca6f57d0d8486d42ed77a739877a208a34f= 22e
# timestamp: 2014-05-11 13:55:53 -0700
# base_revision_id: m= onnier@iro.umontreal.ca-20140511034953-\
# =C2=A0 1mzcrftziwhrw9h= l
#=C2=A0
# Begin patch
=3D=3D=3D modified fi= le 'lisp/subr.el'
--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-04-09 01:48:07 +0000<= /div>
+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-11 20:55:38 += 0000
@@ -1857,10 +1857,14 @@
=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)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nil nil
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0t))
- =C2=A0(let ((file (locate-file l= ibrary
- =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)
- =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))
- =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)= )))
+ =C2=A0(let ((file
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (= locate-file library
+ =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)
+ =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
+ =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 "\\.= elc?\\.gz\\'" library))
+ =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?\\'" library)
+ =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
+ =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))))))
=C2=A0 =C2=A0 = =C2=A0(if interactive-call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (if file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message "Library i= s file %s" (abbreviate-file-name file))

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIHY= 0CiMKQlpoOTFBWSZTWfbc99AABHZ/gDIwFUFQ4//3
8wgABL////BgBs96932joSo= L3t0q2rG2TpgbVEE2kE9J6jNTyaZNNTagHqAAaaeoOYBNMAmQwABM
EwAAAShU02o= AA0AAANAAAAG0qNQNT1MTCaepgmgwBDAI0000EUgRMgalP2mqaZpPVP0U9T0h6jah
kGJo0EVE0aaRgITaJMJoaRieoNAAZMyxwwqXQuSoc5zx7XqLgxjChKpd+GuM3swscixOW2= FuYpwb
BJ76XVaN7ooEkNIl8j4H03G7ZaZmUngNpcGMaPziEkCQaXe13WIEZAjrzU= VAplMmPv1v9TyDhZk/
TOCTEDcwOWPX5fOPrmzaublzrn8a9huAiuc8PAHYZNSwwj= GhSFdSjC5SpYYbMwwpQrOXBEKJ3iZF
xMl+oRaRFCFZtuLh4YuClOwDzJ2cWwwkZCevW+rQM0X3eaEPAlD5B1eGOUYxZmw4cVlwgM= kDZ3GZ
9AtqjnMIiLHfetqjn0CpARpIshrEt/05xJEWdXxLOe+NJoQjuMKkKlnUWz= mFb+kN1g6CdRNKmoiP
XNismTs0wuRr35bDn4u+xGCEADgWqFbY5VAay3aHG6u7TB= 4iYIfEL7zJwFZoUJUM3c3+8duzI+Gw
TRDux3mtEOw6Q5pQdWZPmJiOJlrCNKcdm2BaHY/HpUhRgK0QoJtiadSVUybnyQxg9d/ZQT= HS+Btw
7CqlMt1Lxhg65OAldu/FyOViFxXEMItpVgQNeBKhvHO8sS5hrOBR0qqutn= rT+EWImQ5V23kQTlqx
Fd9ZIWwiyGqDeRU13oRurcJn2BtgIL6CS1uqhvgeodpiWM= d+vZDjQTDE0HY5Uw6xPQahmK4du8xy
e2W5sXMjaOdRESRqGFxkVnUTqMqHoxIuLpmP/IdEJHApoJ1apwziupdVOEDpGWxWb7DEuL= lM22QQ
HWza0l7xPf4ZYl72QOl+XZuqKiVvBkUiubNTzGuZihbGiGqmcryB2wyacp= yqEoJRh29sQJmtZiZt
pFszcI94kc6nnwLmkkNifK9vqQuobBWhKhQLtXdG0hlrVX= IqIOQyLL7DDcxheex8xPZKdjEMEytU
kzdrE3WxZsyEoyQhsxQbhLXMO90f2G6WyRYpm24mRjLZxKxYWUQXErpKlSbSTY97XjMdYv= vZlTZD
ORCO615GiQTND6RrmmfrsoU7lnoZ3CefiGW4rk+sSgcjiR1pBIiSQSIl8n= p6nm2uInuxVqAqHwHE
JEX3WHA5m230El7Dobc9lW9l4cvcho8QPqh+IniDxPK2HC= HlOtFMzOlPwPMOD0Dwz1a9DjU9BJY5
6Fu/mfa9fCHJF+x+5uqFMjn7XfhnHuG9j3JLFes6IXnEraIXdKYTeJGspva7eg4iYPXVDD= sTQIC8
33xlGuvV5sEqFJROfJ8nfWm5hFm3CeftDC7At8jwuQx6fiWIcubjY+8XkV= BUCgvxQFK2tK6JPofR
GtSFpRcJMQsVOp9gac33JNjR5jHMwBkAF6FH0LjRk7eT2a= VLnZXFKQzqcSa6aDGntmRuUjRktEnl
aYpEbgXl2ntPa+jrU8dyLMNHsYaBmPkjiePIfAzO4h74eQO7ufN0Q7m15CQ20vAho8n6oQ= YhY6He
PMGoez7BMLgn0dGTqD8w94OT7Xm4P0YATa8hPUJ0DV4iZvRTYT1BBG4G5i= L3ofJUtGxmnAcINyKK
RiV4/OVmEEKc04jYhEogyEkyCxDg9zkPa2ZhrCrIe9tUHF= qzEqYJR0C0ZBY8EN6tQTihBDreFEMA
I+L8OoATB73QCwNXyE6u8EPlUh9Xg55E3LzE1vD1MMIRaY3OPGzghoJUiPyQxToJATEmpu= CquN72
uweLq6XhgqGgSnuatYGAljGDRArjU6IiSlO1ptukSJDJ56MbIvaNyFhNA5= vvYbODvIItsG+ODIqJ
Nm/oO5mMna3j7GiYdriN4mpGAiTOSG57XmhYhpBT4= CSfgFrwa/WJ6IbkOAPkk2F749yGCFJM2CQR
YDBCaBWJ8xMR8RLx3eg6R4+TvDDZwf/F3JFOFCQ9tz30AA=3D=3D
<= br>




On Sun, May 11, 2014 at 1:45 PM, Alex= Kosorukoff <alex@3form.com> wrote:
The issue is that loca= te-library returns spurious paths like ".*/tramp" or ".*xxx/= tramp.gz" 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 "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= @iro.umontreal.ca> wrote:
> it should be just (".elc" ".elc.g= z" ".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&= #39;d
prefer that behavior? =C2=A0Which concrete cases do you specifically care a= bout?

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

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. =C2=A0Maybe we can accommodate your specific concrete cases in some other way.

I understand that= the bug was there for many years and many people=C2=A0implemented workarou= nds (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 w= hile fixing it. Unit tests can help.
=C2=A0


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


--e89a8f502d04429a1204f9262149-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 17:19:59 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 21:19:59 +0000 Received: from localhost ([127.0.0.1]:59752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjbA6-0000gB-VF for submit@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 ) id 1WjbA4-0000g2-2l for 17467@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 ) id 1WjbA2-0007oe-UE; Sun, 11 May 2014 17:19:54 -0400 From: Glenn Morris To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path References: 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: (Alex Kosorukoff's message of "Sun, 11 May 2014 13:45:12 -0700") Message-ID: <3feh00ko79.fsf@fencepost.gnu.org> 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@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 17:56:23 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 21:56:23 +0000 Received: from localhost ([127.0.0.1]:59789 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjbjK-0001dl-KN for submit@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 ) id 1WjbjJ-0001dW-4R for 17467@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 To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path Message-ID: References: Date: Sun, 11 May 2014 17:56:15 -0400 In-Reply-To: (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@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 18:32:26 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 22:32:26 +0000 Received: from localhost ([127.0.0.1]:59811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjcID-0003jF-L5 for submit@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 ) id 1WjcIA-0003iz-VY for 17467@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@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@fencepost.gnu.org> References: <3feh00ko79.fsf@fencepost.gnu.org> From: Alex Kosorukoff Date: Sun, 11 May 2014 15:31:56 -0700 X-Google-Sender-Auth: ehrs65wUy9dNIRHueZGlzaWmgms Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Glenn Morris Content-Type: multipart/alternative; boundary=089e011827522faab404f92767a2 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org>, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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
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'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>

I did fix the proximal cause already, worked around this fun= ction and patched my emacs, so this bug doesn'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'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.



On Sun, May 11, 2014 at 2:19 PM, Glenn Morris <rgm@gnu.org> wro= te:
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 "tram= p" 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-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 18:55:51 2014 Received: (at 17467) by debbugs.gnu.org; 11 May 2014 22:55:51 +0000 Received: from localhost ([127.0.0.1]:59821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjces-0004Mo-Tl for submit@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 ) id 1Wjceq-0004Ma-GS for 17467@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 To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path Message-ID: References: <8361lcuu1f.fsf@gnu.org> <8338ggus2g.fsf@gnu.org> <831tw0uqyp.fsf@gnu.org> Date: Sun, 11 May 2014 18:55:42 -0400 In-Reply-To: (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 , 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 20:20:53 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:20:53 +0000 Received: from localhost ([127.0.0.1]:59868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjdzA-0007hA-NB for submit@debbugs.gnu.org; Sun, 11 May 2014 20:20:53 -0400 Received: from mail-ob0-f177.google.com ([209.85.214.177]:41189) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjdz7-0007gt-6a for 17467@debbugs.gnu.org; Sun, 11 May 2014 20:20:50 -0400 Received: by mail-ob0-f177.google.com with SMTP id gq1so7066082obb.8 for <17467@debbugs.gnu.org>; Sun, 11 May 2014 17:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5n6APP+rwRdZHGZuKjqLkPKC5IO7T84hTJA1sIA2OBM=; b=l9qcQ/sKkAzEaN1EfSH849IZ5kNrr96tZa8Q9mzVkKrsA5aJBLiyMUq7Ih2BrQcay/ xGwO4VAR/aytih6W10p3KUNoQ6j3+EmrqnuMH884ez6TcN3hBl7J2kELBH1rsw80dxeH ec+eRPu15bkZ0g5O7wjvtaoM0ETb94wCi+IvfVvUR2nEwzhAo4H3FZSOFVo2y5kwrjEA jc7BLwRWQyCUQ0G1obqoNoUtfwc4Isdyk/t1nGcZkhdg1lGBc/jZDL00MSNMEgzOfhIy U1CYNiViPo/pSaAp6w3rXsMRwgcLaZs+xawNblMRSP4cq1AawfIOD5ePhibyaIhgSxVC Q/mA== X-Received: by 10.182.66.170 with SMTP id g10mr29706515obt.49.1399854043528; Sun, 11 May 2014 17:20:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 17:20:23 -0700 (PDT) In-Reply-To: References: From: Alex Kosorukoff Date: Sun, 11 May 2014 17:20:23 -0700 X-Google-Sender-Auth: KItpMBUDeGGuV-LGZZHgvnyR8s8 Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a11c1ed8a00852804f928eb3d X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a11c1ed8a00852804f928eb3d Content-Type: text/plain; charset=UTF-8 On Sun, May 11, 2014 at 2:56 PM, Stefan Monnier wrote: > > The issue is that locate-library returns spurious paths like ".*/tramp" > or > > ".*xxx/tramp.gz" > > I don't see why these are necessarily spurious. Please give very > concrete examples, so as to make it crystal clear why they're spurious. > I think these file names are more appropriate for data files, not executable ones. It is undesirable that a name "tramp.gz" will shadow a valid library file "tramp.elc" that won't be found as a result. When you say those names aren't spurious, do you have a particular example of an emacs elisp library in mind which file name ends with a suffix other than .el .elc .el.gz .elc.gz? I think the main difference is that I assume that this list is exhaustive and you imply that it is not. You can prove me wrong by a single example. > This is both unexpected and incorrect given this function name and > > spec. > > Unexpected to you, obviously, but I'm not convinced it's unexpected in > general (after all, I don't remember other bug-reports in this area) and > definitely not incorrect. See the docstring of `load': > > Execute a file of Lisp code named FILE. > First try FILE with `.elc' appended, then try with `.el', > then try FILE unmodified (the exact suffixes in the exact order are > determined by `load-suffixes'). Environment variable references in > [...] > By incorrect, I only meant that the function fails to do what its name suggests when it returns something other than a library. My understanding is that load is used to load any files, not just libraries. > Of course, there's an ambiguity about how the search is performed, > w.r.t. to whether it does: > > (dolist (s suffixes) (dolist (d load-path) ...))) > or > (dolist (d load-path) (dolist (s suffixes) ...))) > > We do the second, so that a compiled file in a later directory does not > override a non-compiled file in an earlier directory. > Yes, I noticed that require won't attempt to load files like "trump" or "trump.gz" even if they are in the load-path, unlike load that will try to load any file regardless of its suffix. My understanding was that require is used to load libraries, while load is used to load general files. > > Stefan > --001a11c1ed8a00852804f928eb3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, May 11, 2014 at 2:56 PM, Stefan Monnier <= monnier@iro.umontreal.ca> wrote:
> The issue is that locat= e-library returns spurious paths like ".*/tramp" or
> ".*xxx/tramp.gz"

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

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

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

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

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

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

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

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

=

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

--001a11c1ed8a00852804f928eb3d-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 20:32:56 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:32:56 +0000 Received: from localhost ([127.0.0.1]:59872 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjeAp-00081D-Jr for submit@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 ) id 1WjeAn-000815-A5 for 17467@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 ) id 1WjeAl-0002MS-NK; Sun, 11 May 2014 20:32:51 -0400 From: Glenn Morris To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path References: 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: 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@debbugs.gnu.org, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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. From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 20:42:20 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:42:20 +0000 Received: from localhost ([127.0.0.1]:59876 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjeJv-0008IF-9z for submit@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 ) id 1WjeJr-0008Hs-Eo for 17467@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@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: References: <8361lcuu1f.fsf@gnu.org> <8338ggus2g.fsf@gnu.org> <831tw0uqyp.fsf@gnu.org> From: Alex Kosorukoff Date: Sun, 11 May 2014 17:41:48 -0700 X-Google-Sender-Auth: E3q0HntCQEW552_O6vtCjUE7vNU Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Stefan Monnier Content-Type: multipart/alternative; boundary=089e01182752aa690704f929375b X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: Eli Zaretskii , 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --089e01182752aa690704f929375b Content-Type: text/plain; charset=UTF-8 On Sun, May 11, 2014 at 3:55 PM, Stefan Monnier 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
On Sun, May 11, 2014 at 3:55 PM, Stefan Monnier <= monnier@iro.umontreal.ca> wrote:
> Yes, this makes sense. Here is a patc= h that the issues you mentioned.

I'm still not sure which situations you want to exclude, so it= 9;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 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

> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 (locate-file library
> + =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)
> + =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 ".el.gz" library)= )

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

This is because if a user speci= fied .el.gz already, we shouldn'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'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;", ".gz"). 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'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.
=C2=A0


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

--089e01182752aa690704f929375b-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 21:36:23 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 01:36:23 +0000 Received: from localhost ([127.0.0.1]:59893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjfAE-0001M2-Ny for submit@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 ) id 1WjfAB-0001Lk-TA for 17467@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@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: References: From: Alex Kosorukoff Date: Sun, 11 May 2014 18:35:54 -0700 X-Google-Sender-Auth: ptqvxXk5Jj1UDEODJwj34Vk_egY Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Glenn Morris Content-Type: multipart/alternative; boundary=089e0112c5d20d2eb004f929f972 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org>, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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
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.


On Sun, May 1= 1, 2014 at 5:32 PM, Glenn Morris <rgm@gnu.org> 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" wi= ll 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 =C2=A0ex= ample of an
> emacs elisp library in mind which file name ends with a suffix other t= han
> .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:

=C2=A0 =C2=A0 =C2=A0 =C2=A0When Gnus starts, it will read the `gnus-site-in= it-file'
=C2=A0 =C2=A0 (`.../site-lisp/gnus-init' by default) and `gnus-init-fil= e' (`~/.gnus'
=C2=A0 =C2=A0 by default) files. =C2=A0These are normal Emacs Lisp files an= d can be used
=C2=A0 =C2=A0 to avoid cluttering your `~/.emacs' and `site-init' f= iles with Gnus
=C2=A0 =C2=A0 stuff. =C2=A0Gnus will also check for files with the same nam= es as these,
=C2=A0 =C2=A0 but with `.elc' and `.el' suffixes. =C2=A0In other wo= rds, if you have set
=C2=A0 =C2=A0 `gnus-init-file' to `~/.gnus', it will look for `~/.g= nus.elc',
=C2=A0 =C2=A0 `~/.gnus.el', and finally `~/.gnus' (in this order).<= br>
and it uses locate-library to do that.

--089e0112c5d20d2eb004f929f972-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 22:03:26 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 02:03:26 +0000 Received: from localhost ([127.0.0.1]:59910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjfaP-0002C2-Bx for submit@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 ) id 1WjfaM-0002Bf-6U for 17467@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@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: References: From: Alex Kosorukoff Date: Sun, 11 May 2014 19:02:56 -0700 X-Google-Sender-Auth: wLj1mdpt3Gj4kdWi2QKKG6zBZqU Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Glenn Morris Content-Type: multipart/alternative; boundary=089e0149cc30be9bb104f92a5988 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org>, Stefan Monnier X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 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 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
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.


On Sun, May 1= 1, 2014 at 6:35 PM, Alex Kosorukoff <alex@3form.com> 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 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.


On Sun, May 1= 1, 2014 at 5:32 PM, Glenn Morris <rgm@gnu.org> 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" wi= ll 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 =C2=A0ex= ample of an
> emacs elisp library in mind which file name ends with a suffix other t= han
> .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:

=C2=A0 =C2=A0 =C2=A0 =C2=A0When Gnus starts, it will read the `gnus-site-in= it-file'
=C2=A0 =C2=A0 (`.../site-lisp/gnus-init' by default) and `gnus-init-fil= e' (`~/.gnus'
=C2=A0 =C2=A0 by default) files. =C2=A0These are normal Emacs Lisp files an= d can be used
=C2=A0 =C2=A0 to avoid cluttering your `~/.emacs' and `site-init' f= iles with Gnus
=C2=A0 =C2=A0 stuff. =C2=A0Gnus will also check for files with the same nam= es as these,
=C2=A0 =C2=A0 but with `.elc' and `.el' suffixes. =C2=A0In other wo= rds, if you have set
=C2=A0 =C2=A0 `gnus-init-file' to `~/.gnus', it will look for `~/.g= nus.elc',
=C2=A0 =C2=A0 `~/.gnus.el', and finally `~/.gnus' (in this order).<= br>
and it uses locate-library to do that.


--089e0149cc30be9bb104f92a5988-- From debbugs-submit-bounces@debbugs.gnu.org Sun May 11 22:18:13 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 02:18:13 +0000 Received: from localhost ([127.0.0.1]:59915 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjfoi-0002fa-Kj for submit@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 ) id 1Wjfof-0002fO-A5 for 17467@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 To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path Message-ID: References: Date: Sun, 11 May 2014 22:18:03 -0400 In-Reply-To: (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@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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)) From debbugs-submit-bounces@debbugs.gnu.org Mon May 12 00:36:52 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 04:36:52 +0000 Received: from localhost ([127.0.0.1]:59988 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wjhyt-0008Mu-3z for submit@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 ) id 1Wjhyp-0008Ma-Vs for 17467@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@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: References: From: Alex Kosorukoff Date: Sun, 11 May 2014 21:36:22 -0700 X-Google-Sender-Auth: apUIXmfzmeAbLO26mf2VK109Vk8 Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a1134bdda74595a04f92c7ec7 X-Spam-Score: 0.4 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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@3form.com-20140512042218-zjdg3v68bbja2rj2 # target_branch: :parent # testament_sha1: 330ab5b4527e49ea46d8d16a6d47e5822247ce77 # timestamp: 2014-05-11 21:23:50 -0700 # base_revision_id: monnier@iro.umontreal.ca-20140511034953-\ # 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 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
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@3form.com-20140512042218-zjdg3v68bbja2rj2
= # target_branch: :parent
# testament_sha1: 330ab5b4527e49ea46d8d1= 6a6d47e5822247ce77
# timestamp: 2014-05-11 21:23:50 -0700
# base_revision_id: m= onnier@iro.umontreal.ca-20140511034953-\
# =C2=A0 1mzcrftziwhrw9h= l
#=C2=A0
# Begin patch
=3D=3D=3D modified fi= le 'lisp/subr.el'
--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-04-09 01:48:07 +0000<= /div>
+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-12 04:22:18 += 0000
@@ -1857,10 +1857,14 @@
=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)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0nil nil
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0t))
- =C2=A0(let ((file (locate-file l= ibrary
- =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)
- =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))
- =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)= )))
+ =C2=A0(let ((file
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (= locate-file
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0library
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(or path load-path)
+ =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0(unless nosuffix
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(if (string-match "\\.= elc?\\(\\.gz\\)?\\'" library)
+ =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)
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(= get-load-suffixes))))))
=C2=A0 =C2=A0 =C2=A0(if interactive-call
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 (if file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (me= ssage "Library is file %s" (abbreviate-file-name file))

# Begin bundle
IyBCYXphYXIgcmV2aXNpb24gYnVuZGxlIH= Y0CiMKQlpoOTFBWSZTWdDpudEABgd/gDN0FUFQ4//3
8wgABL////BgCI+FAA0AAAAAAAAMkk2p6mmgBoDQaADTQAABoGlQZPSMmynpqDJo0AaZAD= TIyABz
CYBMAJhMJpgAAEyaaBjmEwCYATCYTTAAAJk00DHMJgEwAmEwmmAAATJpoG= CpRAJoATEDRDQCYJT1
NNqY1NkylAzQWMD1e2laABxxxTQHTYJXxEfUiG4Q6b22N1= Uag1frP3pbf2aB7XuzlcK84k5F8VNn
K7C8uNBohJUOdK//P1n8bZy3bNmOF6+X2+h/c3FChQf7/zDTaaSkcqN+uu/7XlheXcb+7R= LjabTu
P27z/NnCO/mwLDn/FKKlFBiUHHTs3fk/3T+uRYAsB4BdK8urI8LfFgkLYy= S2WyCO5UQmtUUEMWlG
zCpPr9qvxRVZXznh5+Va2K/lUqoc7pu4dvX+RkjytniPma= D/hD4GJ5o2+573zPmWFJ/EuPsT5sF7
mXta2bUb099NVld5uEfL5kp0ltH3PA47Nta1rWta1+Px8PlTbiJYcq/XF1wJvdameWVgil= nVjdWk
xvQv+zpoWXSQuRejL+HbVarMLMpf26a1ywJSizNrtJZC9haxswi4/Wmd6O= CO9G+wsVHDcVhaWztM
teiJdp29o3eo03xKEoRxYpFxebbktJwu36bqr+zRhdy4bD= kjST9kyybzSIsJara5G044Zf3G7Zwf
rwTPYjoTrna5aCap2U6SZDiYMOiNqNrDdxpZZz4Z8+2YtFV/bmf8WdlHKytPxSy4msoI0p= rJRJhc
m7v5JxU8GCzQ0GGWom/Cps09tsEupZqmGlKuiquk7JkArLJwBSQA4Yjggs= wlu0AkkXDE0r6pv4WT
NbwXqs+xr7MNSxGqmxhJqL64VoyLuN91Nd+ei223D9hFiP= Ym5GzDDKUpLK8M9QjffUmGmmBLkzrf
Teowa7yU3XWYyOXibKFKFGNqK3NEpa30HEZNbNgs3adVJnkuRozdqNRu0YeNX6IsGAizX1= 0tm062
79MxxRqpvW5o32KotcDbqb11VlyODLRe1f2K2NTJotYfyT0JWXreaOGSzT= fZOK9WyxoZ25Uo3b54
W4drBjaorX+kyXcGtqDsNFpQacOWlru+SPl62/bMmubsqu= Hfsus02LF3ZfoqXNFYbjFJ5Iu0sW3D
JUlLM0USi9Rwkb7tSjxpuNunLnlfYjORmX18fCsi/GccJvbjQzWGPA219SK604WzHpdymk= tuJ2rt
3DabbSZ6GmLmdIXZs4t2zTbZjOtd/DJdjctlDeLWWu9sxuUWYV1vdPij3W= 5YFZNsm7EKlk1lLDMp
eXlSWlSULylowiX4FDcdD/senkaPEo+PhSlKUpWhYUPE/Y= 4HL7UfQR5nka00UpIpQp/FbDafVH7v
SlNcrw3nAyg/HvsHSm47lLO24PV39/2S71+7Q8dczcOrDyVvyR9/nJluXcDxiWnqdqnhFF= VKxRVS
sUVUr+57e47jE2I+WwiyRYj0jXQ2JcVPjg5O5h320596L/cv73bXVdYlGh= RlOa7u8ZPzJ0Ocj6E+
qPeHBzer5Y6eV99k8rrNS6RvYbqccMPyn0OU9ibOeezo1X= PzRXPDn0Ydvmeo7+yhuEcD2zC6TLc7
vaadm+vVGor0ncou2w8MdBNbmuNBM+/LplXbXKdGC2i7fLtvknrGtGo77yZ+MnclEya8eK= vGmv64
XfYorZcurZXPLLuPQtuk0lKmBnEw0Ph7i9su2Mu967yUy8ftNzAnTuNvHG= 7Tcfc09T1pL8d2V55P
Syw9ffws/YoM5vRu5j4Eokx8fA8jt8z8Cwp= keYp5zQFSRiS0/NgdCs9NnnPHt9S73188uMxY4PB4
+BLbu7TjqW4W+NmyaRr1EsehjuHwkn1+H0KT5H4NMk920RZHQ8JQtjinJHwg0zsu8Uek5T= rFI9lP
YGnrPfOBOpic0U7uGqRTWcz+iUKl5vOwdILBz+MTXojDuN5acA/Q+AbT2n= Saz+SkjAu0p7E3IwTq
jvjicomB3yO6J1KQaQ0lZDzifR1qV6ZlP5MhHuR/54+RSP= wXeB6z+bpfNCptPYQ4iN6KlYvl9TQe
ZvHUwLDSXFR7ZfcGkuLIlhRM8zgZC4wOwl5FhhUlCddRkTZEr7D8vAkYB1N4vjge2J4GmC= fWwn9H
E3bWBufVGk49ChQlF6wYGfK80E5ouUo9CZp7EULIlkk2FxGbE8DUOUy9mM= fNM4idCy3aXl1p7JqW
FIUFpxKF1SsajXSlFKUpkaAoXz20lKSlJTEtMCXxOkeo/s= ULzRN0oUv1Ixp2FZciwsPuK7CiKmsx
HmeVwz6mkZRNAUilSypNp1nqJeThSSfRFp9DE7C72IvT7kzJ2BtjGUjVPX5E1k0WmBRKCK= QoTCSL
kfojNHrRqRn90b6uz0mmNfbO9Nh/+LuSKcKEhodNzog=3D
=



On Sun, May 11, 2014 at 7:18 PM, Stefan Monnier <monnier@iro.umontr= eal.ca> wrote:
> I think these file names are more appropriate for data= files, not
> executable ones. =C2=A0It is undesirable that a name "tramp.gz&qu= ot; 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. =C2=A0So far we have = simply
considered "if it hurts, don't do it". =C2=A0And it worked we= ll 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. =C2=A0So 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.


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


=3D=3D=3D modified file 'lisp/subr.el'
--- lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-04-15 17:03:15 +0000
+++ lisp/subr.el =C2=A0 =C2=A0 =C2=A0 =C2=A02014-05-12 02:15:04 +0000
@@ -1878,10 +1878,15 @@
=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)))
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0nil nil
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0t))
- =C2=A0(let ((file (locate-file library
- =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)
- =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))
- =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))))
+ =C2=A0(let* ((suffixes
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(nconc (unless nosuffix (get-load-suffi= xes))
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (when (or (file-n= ame-absolute-p library)
+ =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 "foo.el") 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 "foo") should not find /bar/foo.gz= .
+ =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 "\\.el\\(\\.[[:alnum:]]+\\)?"
+ =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)= )
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 load-file-= rep-suffixes)))
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 (file (locate-file library (or path load-path= ) suffixes)))
=C2=A0 =C2=A0 =C2=A0(if interactive= -call
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (if file
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (message "Library is file %s= " (abbreviate-file-name file))


--001a1134bdda74595a04f92c7ec7-- From debbugs-submit-bounces@debbugs.gnu.org Mon May 12 02:39:14 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 06:39:14 +0000 Received: from localhost ([127.0.0.1]:60092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjjtJ-0005FX-S4 for submit@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 ) id 1WjjtG-0005F1-1Q for 17467@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 To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path Message-ID: References: Date: Mon, 12 May 2014 02:39:04 -0400 In-Reply-To: (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@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Mon May 12 13:46:42 2014 Received: (at 17467) by debbugs.gnu.org; 12 May 2014 17:46:42 +0000 Received: from localhost ([127.0.0.1]:60994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1WjuJF-0003iw-Ib for submit@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 ) id 1WjuJC-0003ii-LK for 17467@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@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: References: From: Alex Kosorukoff Date: Mon, 12 May 2014 10:46:12 -0700 X-Google-Sender-Auth: lY5Ootp5ibv35FR3UzbMlZMT2BA Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a113a98d0285cda04f93787bf X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) --001a113a98d0285cda04f93787bf Content-Type: text/plain; charset=UTF-8 On Sun, May 11, 2014 at 11:39 PM, Stefan Monnier 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
On Sun, May 11, 2014 at 11:39 PM, Stefan Monnier <= monnier@iro.umontreal.ca> wrote:
> variant matched tramp.el.old which is= not a valid library name.

Who cares? =C2=A0The point is that if the user asks to load foo.el.ol= d, we
should consider load-file-rep-suffixes, whereas for "foo" we shou= ldn't.
I'm not particularly worried about finding files with name "foo.el= .old.el".
=C2=A0
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?\\' (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= 't be extended. Am I missing something?

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

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

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

> + =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)
> + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(get-load-suffixes))= ))))

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

Got it.

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

--001a113a98d0285cda04f93787bf-- From debbugs-submit-bounces@debbugs.gnu.org Thu May 15 15:40:49 2014 Received: (at 17467) by debbugs.gnu.org; 15 May 2014 19:40:49 +0000 Received: from localhost ([127.0.0.1]:36375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl1WK-0006QV-1X for submit@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 ) id 1Wl1WH-0006QK-Li for 17467@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 To: Alex Kosorukoff Subject: Re: bug#17467: 24.3; locate-library returning spurious path Message-ID: References: Date: Thu, 15 May 2014 15:39:00 -0400 In-Reply-To: (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@iro.umontreal.ca X-Spam-Status: No X-Spam-Score: -3.0 (---) X-Debbugs-Envelope-To: 17467 Cc: 17467@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 From debbugs-submit-bounces@debbugs.gnu.org Thu May 15 19:57:57 2014 Received: (at 17467) by debbugs.gnu.org; 15 May 2014 23:57:57 +0000 Received: from localhost ([127.0.0.1]:36475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl5XA-0006KT-JK for submit@debbugs.gnu.org; Thu, 15 May 2014 19:57:57 -0400 Received: from mail-qc0-f174.google.com ([209.85.216.174]:51959) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1Wl5X8-0006KD-Fd for 17467@debbugs.gnu.org; Thu, 15 May 2014 19:57:55 -0400 Received: by mail-qc0-f174.google.com with SMTP id x13so3099876qcv.33 for <17467@debbugs.gnu.org>; Thu, 15 May 2014 16:57:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HZsNJTp+vki3URQbmJICb3iN/ht1o9jzZOdfJudUGjE=; b=I46uX42nMGqr4cy1hlsF27aFfV06yqpjE9TMJdz0Eg7FXlB3dYJO4J6x7MnloQidEy yHHg9oLUYOKH114dF9+QaI7C1iN0CZ4I10zAZtJlfuSd2uA7kPcUYaULDaP8jamyFvEH zq8lRpVfunAji081Ybz3KPkyuZr1MFM3jvcPoX0jQVZ8E5p8H5nfFPlHjN3LJ5Sci4+g HWwjD+2S0wTGMCDeiuL4yam6oByG1/AR942q/dMpAFuyPBQjGLZecc+SXB8HsWgORcaC 6rILs5TST3mMwv/ENn6t3vUOsk0D5Ts6uVY0XeRDgXri36ol+a95iMkPGg6GUBGOOPZi fH7w== X-Received: by 10.140.94.39 with SMTP id f36mr19667774qge.64.1400198268818; Thu, 15 May 2014 16:57:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.96.195 with HTTP; Thu, 15 May 2014 16:57:27 -0700 (PDT) In-Reply-To: References: From: Alex Kosorukoff Date: Thu, 15 May 2014 16:57:27 -0700 X-Google-Sender-Auth: vOctSakizhfvn690s1nDWJzSin0 Message-ID: Subject: Re: bug#17467: 24.3; locate-library returning spurious path To: Stefan Monnier Content-Type: multipart/alternative; boundary=001a113a98d06d9d8704f9791051 X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 17467 Cc: 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) --001a113a98d06d9d8704f9791051 Content-Type: text/plain; charset=UTF-8 On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier wrote: > > locate-library incorrectly generates a set of suffixes to extend the > > base library name (".elc" ".elc.gz" ".el" ".el.gz" "" ".gz"), while it > > should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is > > nil. > > FWIW, this simply reflects what `load' does, so changing it in > `locate-library' would mean that it doesn't do what `load' does, which > I would count as a bug. > I agree with you that locate library should do what load does. > The main issue I see is that `load' includes a `must-suffix' argument > which provides the behavior you're looking for (and which is used by > `require') whereas locate-library doesn't provide it. > > > This leads to spurious paths found, like name.gz. I found > > this issue because (locate-library "tramp") was returning > > "/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc". The workaround > > is (locate-file "tramp" load-path (get-load-suffixes)) > > IIUC the problem you had was with `load' rather than with > `locate-library', so I think what this boils down to is that the `load' > that looks for `trump' should be changed to provide `must-suffix'. > WDYT? > In fact, I was looking for a function that would locate library and return the path to it, so I could compile the explicit path into .elc file that will avoid searching load-path and save time when it is run. locate-library seems like a perfect tool for this purpose, but turned out to be not as useful as it sounds because it is not currently capable of correctly reproducing search behavior of load or require. As a result, I switched to locate-file. This currently seems to be the only reliable way to find correct paths to libraries. I think we could make locate-library more useful by extending it in one of two possible ways. It can either accept symbol argument as well as string and behave exactly like require does in this case (currently it will just fail with error if given a symbol). An alternative way is to add an optional must-suffix argument to make it consistent with load. Both ways will keep it backward compatible and will allow it to emulate the logic of both load and require. > > > Stefan > --001a113a98d06d9d8704f9791051 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier <= monnier@iro.umontreal.ca> wrote:
> locate-library incorrec= tly generates a set of suffixes to extend the
> base library name (".elc" ".elc.gz" ".e= l" ".el.gz" "" ".gz"), while it
> should be just (".elc" ".elc.gz" &= quot;.el" ".el.gz") when nosuffix is
> nil.

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

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

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

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

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


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

--001a113a98d06d9d8704f9791051-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 06:24:22 2020 Received: (at control) by debbugs.gnu.org; 25 Aug 2020 10:24:22 +0000 Received: from localhost ([127.0.0.1]:60392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAW7p-0001sP-Oz for submit@debbugs.gnu.org; Tue, 25 Aug 2020 06:24:21 -0400 Received: from quimby.gnus.org ([95.216.78.240]:39730) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAW7o-0001sA-33 for control@debbugs.gnu.org; Tue, 25 Aug 2020 06:24:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=9GO76OL4r2WsDtY8wbkNhSxvIxulMyPGCuWvvhpctZM=; b=Vwu66H59xSQJduLR10jGlzGU7G 2Ncfc9UXwgFXfOpUeDfeoEP8c8Qzn+qDEv0VV9ufugiBaNj9AuLXmqRYn3Y8kKBeRMMEkA0WWr+zp vJf+9EI/WQ4fh6pxwj8+xl6il8JfI1GsGK881WiEe/JTnpi5EcSj4tpKop6gZhA57Nc0=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAW7f-0004Eu-SU for control@debbugs.gnu.org; Tue, 25 Aug 2020 12:24:14 +0200 Date: Tue, 25 Aug 2020 12:24:10 +0200 Message-Id: <87zh6jaur9.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #17467 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 17467 + patch quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 17467 + patch quit From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 06:39:20 2020 Received: (at 17467) by debbugs.gnu.org; 25 Aug 2020 10:39:20 +0000 Received: from localhost ([127.0.0.1]:60417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAWMK-0004VZ-2g for submit@debbugs.gnu.org; Tue, 25 Aug 2020 06:39:20 -0400 Received: from quimby.gnus.org ([95.216.78.240]:39890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAWMI-0004VM-7i for 17467@debbugs.gnu.org; Tue, 25 Aug 2020 06:39:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=i8cuK2SCVVmpcpWccAsAIzgDpwGX/UXFtdqjXyKDQlQ=; b=l3qljYYnVRR77BwJ+5y5QJkjF6 7AwTVfzRdsgn5wrGnnouaHVyWvFDLbGwxkkL9LLKF6YvtnfK9vYet7qGArOIIP4lAzbNxJaStxvzk MjbkRnHefM1jyMX6CRCqjaYkv8b4IZm5Z2lqUy4PGvfZ7l914WeeeAN/i2KlraQQhDUw=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAWM8-0004Qz-6I; Tue, 25 Aug 2020 12:39:10 +0200 From: Lars Ingebrigtsen To: Stefan Monnier Subject: Re: bug#17467: 24.3; locate-library returning spurious path References: X-Now-Playing: Coil's _The Sound Of Musick_: "Journey To Avebury" Date: Tue, 25 Aug 2020 12:39:06 +0200 In-Reply-To: (Stefan Monnier's message of "Sun, 11 May 2014 22:18:03 -0400") Message-ID: <87y2m3au2d.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier writes: > 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 th [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17467 Cc: Alex Kosorukoff , 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: > 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. I've respun the patch for Emacs 28. It sounds reasonable to me, but the use case isn't really compelling. It breaks the so-long-tests-commentary test, which basically does: (finder-commentary "so-long") So I'm not sure whether it makes sense to proceed with this change... diff --git a/lisp/subr.el b/lisp/subr.el index a58a873a33..6eb2f61eb0 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -2302,10 +2302,15 @@ locate-library string. When run interactively, the argument INTERACTIVE-CALL is t, and the file name is displayed in the echo area." (interactive (list (read-library-name) 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)) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 10:23:07 2020 Received: (at 17467) by debbugs.gnu.org; 25 Aug 2020 14:23:07 +0000 Received: from localhost ([127.0.0.1]:35551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAZqt-0005hb-NJ for submit@debbugs.gnu.org; Tue, 25 Aug 2020 10:23:07 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAZqs-0005gU-5X for 17467@debbugs.gnu.org; Tue, 25 Aug 2020 10:23:06 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 929A18088B; Tue, 25 Aug 2020 10:23:00 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 121958093D; Tue, 25 Aug 2020 10:22:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1598365379; bh=3rA1FG1A4iFoffumdwAnYbHk4IwGpUYIVyN84Qcw3u4=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=ltpGV66BHXwplx3NMISRlNEc1GHxDN4fEOGpgJLFJUVmeO+qQf0Dboz9CjoilMDvN zz9VLLyJFO7l6+pcEyo5DV1Pfy8rVBmv9ivjA2L1386yvznoespIeiLiyNZ7b8F6nW NG2/F99OydvxoQ2GOyCfWjneN8oRAkQXLPjpUN1FCViLvgLYOt8W8mGbrDS8x2AoLv lcfa/b9bWC69VRCHUNTK6p3aXTVV++zL6tPwk4piWNM+rOibA7xwIRnceYpfw0K1RB CekT6vhJiw/LzQ3+VBr2gYZYuoLAAlxeCY4GLGB2Dzk0ejUWKHlUfJ8048kmS4sfsD 27W0a4B6IV9Fg== Received: from alfajor (unknown [45.72.246.108]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D92EB120225; Tue, 25 Aug 2020 10:22:58 -0400 (EDT) From: Stefan Monnier To: Lars Ingebrigtsen Subject: Re: bug#17467: 24.3; locate-library returning spurious path Message-ID: References: <87y2m3au2d.fsf@gnus.org> Date: Tue, 25 Aug 2020 10:22:58 -0400 In-Reply-To: <87y2m3au2d.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 25 Aug 2020 12:39:06 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.060 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 17467 Cc: Alex Kosorukoff , 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > I've respun the patch for Emacs 28. It sounds reasonable to me, but the > use case isn't really compelling. It breaks the > so-long-tests-commentary test, which basically does: > > (finder-commentary "so-long") Why does it fail? Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 10:25:21 2020 Received: (at 17467) by debbugs.gnu.org; 25 Aug 2020 14:25:21 +0000 Received: from localhost ([127.0.0.1]:35559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAZt3-0005lO-A2 for submit@debbugs.gnu.org; Tue, 25 Aug 2020 10:25:21 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAZt0-0005l9-OY for 17467@debbugs.gnu.org; Tue, 25 Aug 2020 10:25:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=Nmuhj8BRaKuph3j+rfIT63kyo/M125AxaVNEFlR4vYE=; b=TKHfbMk6S5OZZMm5ny4yo52iUV BxyRxlF2kiHHz+A2WO9R8KIqQX6lQpCQlry5RdfgGvTYg8VOi/stvw7Yap6fYuVYCdzovyXawfIrA BbKA8WoQKkl4i1fASdhGpGnjxSsDPW5L28U6FiLoXTonNqiw5+H/YxdPFFKFcvRtKjhQ=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAZsr-0006Yq-QN; Tue, 25 Aug 2020 16:25:12 +0200 From: Lars Ingebrigtsen To: Stefan Monnier Subject: Re: bug#17467: 24.3; locate-library returning spurious path References: <87y2m3au2d.fsf@gnus.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAD1BMVEUjHyEhHB1VUVO6 sZ3///8XRmjUAAAAAWJLR0QEj2jZUQAAAAd0SU1FB+QIGQ4WF8m1vfoAAAG8SURBVDjLdVPbkcQw CAOuAfA1YJMGdpL+ezsJO4n34zyzsw6yeAgQWUcjXPYTEdPunop/508L4UPHe7+6h/WbkUFWxysY w2m3TAIuatnTwhlm4DMXoI5bjuDxYR0AeSmd9j5T8o7L7arscHDldcp4AZrxpRcup9Q1ciZmOSSK cQGIxWAqjKwHEDBwtUeLNlb90kZXtarGCyg8eOuu2bK0gkx3HdL6gAJOwKWeTkI0ZKULWDXP44IY Ygwfdr52SD2yWsAYx3QvTq8+joGklEA7v3wdAwUWEAcjZ2kDpIBqYK/wF8/HoUCfDIme5wNsDIM8 9LUAdH0BqANd2xilrrJnOdpnAyhGMQar2rJij4uxK8JCIOKMsQDxOZbxAPoqpY7YuqZx97IaYGMB lFJ1k+uZdr8dekmv/q6BvjmJqHwBWApMsaquNYAbmzOkOaAPLTXIzeaw+ANIKSItLWu9GqRr19AC nEByRdS99oUiVYAFIDYvmA/xxsGOAqrehn2rlH4+D2MOYTEg+++ocibAhbX5AvNLB0zXIn5Oito4 g8G5Ywwp4FpAycWlX7Jb3gwtjcLvfux9qaX4NmznX+APxEFJima8pW0AAAAldEVYdGRhdGU6Y3Jl YXRlADIwMjAtMDgtMjVUMTQ6MjI6MjIrMDA6MDB/zcLuAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIw LTA4LTI1VDE0OjIyOjIyKzAwOjAwDpB6UgAAAABJRU5ErkJggg== X-Now-Playing: Various's _The Wire Tapper 53_: "Qzios - El Amargo (Wire Edit)" Date: Tue, 25 Aug 2020 16:25:08 +0200 In-Reply-To: (Stefan Monnier's message of "Tue, 25 Aug 2020 10:22:58 -0400") Message-ID: <87lfi27qgr.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stefan Monnier writes: >> I've respun the patch for Emacs 28. It sounds reasonable to me, but the >> use case isn't really compelling. It breaks the >> so-long-tests-commentary test, which basically does: >> >> (finder-comm [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17467 Cc: Alex Kosorukoff , 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> I've respun the patch for Emacs 28. It sounds reasonable to me, but the >> use case isn't really compelling. It breaks the >> so-long-tests-commentary test, which basically does: >> >> (finder-commentary "so-long") > > Why does it fail? I didn't really investigate -- I thought if we weren't going to do this after all, then there wasn't much point spending time on it. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 12 21:42:07 2020 Received: (at 17467) by debbugs.gnu.org; 13 Oct 2020 01:42:07 +0000 Received: from localhost ([127.0.0.1]:44559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS9KI-0000Er-Mb for submit@debbugs.gnu.org; Mon, 12 Oct 2020 21:42:06 -0400 Received: from quimby.gnus.org ([95.216.78.240]:40280) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS9KG-0000EC-J1 for 17467@debbugs.gnu.org; Mon, 12 Oct 2020 21:42:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=EsksKyTWhBOKnSda0tpoP/S3SKBogmHa5oDFnuZFGVE=; b=m3Xe8JAid3qwHB6RPV31uI6FPC 3oyUshmxNx0bFZWnls46/kN5K151xowshzExCB4kCufZY5RWPrdpSC/IetsZwbpVZ3e+r0EGS1WC/ 9vNlQm/mtm4FQ5CRYedW+/1G8g14s1PkpP1nbQKn0i6o7p2A2ZqHFUyv6gKInuE3LPRo=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kS9K1-0000VL-FF; Tue, 13 Oct 2020 03:41:52 +0200 From: Lars Ingebrigtsen To: Stefan Monnier Subject: Re: bug#17467: 24.3; locate-library returning spurious path References: <87y2m3au2d.fsf@gnus.org> X-Now-Playing: Matmos's _A Chance To Cut Is A Chance To Cure_: "Spondee" Date: Tue, 13 Oct 2020 03:41:48 +0200 In-Reply-To: <87y2m3au2d.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 25 Aug 2020 12:39:06 +0200") Message-ID: <87362iaomb.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Lars Ingebrigtsen writes: > So I'm not sure whether it makes sense to proceed with this change... This was six weeks ago, and it didn't seem like there was much enthusiasm for this change, so I'm closing this bug report. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 17467 Cc: Alex Kosorukoff , 17467 <17467@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > So I'm not sure whether it makes sense to proceed with this change... This was six weeks ago, and it didn't seem like there was much enthusiasm for this change, so I'm closing this bug report. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 12 21:42:06 2020 Received: (at control) by debbugs.gnu.org; 13 Oct 2020 01:42:06 +0000 Received: from localhost ([127.0.0.1]:44557 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS9KI-0000Ep-FK for submit@debbugs.gnu.org; Mon, 12 Oct 2020 21:42:06 -0400 Received: from quimby.gnus.org ([95.216.78.240]:40286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kS9KG-0000EE-NT for control@debbugs.gnu.org; Mon, 12 Oct 2020 21:42:05 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=uH7L78+cob5Al9JjTu9aLxL08Se9MiA7PcHwDzXBHGg=; b=Px8BU8p1oPgOueifjU1sCglUP/ oK6rcxl079vmrZPJGgG/04wyDbC7ss8ffCGSOpRIK4MmY3U3ayQMP9LhsBgM+TCKOV/Zb1gRu8EGS N6pgV24cUn+Gy/JIbxiWbQujO5KCgFGPzzWFdk8IOD5NkvIRAPKC9doxHrIg4Hklk+M8=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kS9K8-0000VZ-VE for control@debbugs.gnu.org; Tue, 13 Oct 2020 03:41:59 +0200 Date: Tue, 13 Oct 2020 03:41:55 +0200 Message-Id: <871ri2aom4.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #17467 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: close 17467 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) close 17467 quit From unknown Mon Jun 23 16:46:19 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 10 Nov 2020 12:24:08 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator