From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alex Kosorukoff Newsgroups: gmane.emacs.bugs Subject: bug#17467: 24.3; locate-library returning spurious path Date: Mon, 12 May 2014 10:46:12 -0700 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a113a98d0285cda04f93787bf X-Trace: ger.gmane.org 1399916844 21300 80.91.229.3 (12 May 2014 17:47:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 May 2014 17:47:24 +0000 (UTC) Cc: 17467 <17467@debbugs.gnu.org> To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 12 19:47:16 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WjuJo-00063J-0D for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 May 2014 19:47:16 +0200 Original-Received: from localhost ([::1]:39118 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjuJn-0005JD-Gh for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 May 2014 13:47:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42467) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjuJf-0005Iv-MN for bug-gnu-emacs@gnu.org; Mon, 12 May 2014 13:47:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjuJa-0004si-Rj for bug-gnu-emacs@gnu.org; Mon, 12 May 2014 13:47:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:43643) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjuJa-0004sb-NG for bug-gnu-emacs@gnu.org; Mon, 12 May 2014 13:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjuJa-0003ju-8i for bug-gnu-emacs@gnu.org; Mon, 12 May 2014 13:47:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Kosorukoff Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 May 2014 17:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17467 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17467-submit@debbugs.gnu.org id=B17467.139991680214323 (code B ref 17467); Mon, 12 May 2014 17:47:02 +0000 Original-Received: (at 17467) by debbugs.gnu.org; 12 May 2014 17:46:42 +0000 Original-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 Original-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 Original-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) Original-Received: by 10.140.96.195 with HTTP; Mon, 12 May 2014 10:46:12 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: lY5Ootp5ibv35FR3UzbMlZMT2BA X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:88978 Archived-At: --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--