From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alex Kosorukoff Newsgroups: gmane.emacs.bugs Subject: bug#17467: 24.3; locate-library returning spurious path Date: Sun, 11 May 2014 17:41:48 -0700 Message-ID: References: <8361lcuu1f.fsf@gnu.org> <8338ggus2g.fsf@gnu.org> <831tw0uqyp.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e01182752aa690704f929375b X-Trace: ger.gmane.org 1399855404 31903 80.91.229.3 (12 May 2014 00:43:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 May 2014 00:43:24 +0000 (UTC) Cc: 17467 <17467@debbugs.gnu.org> To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon May 12 02:43: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 1WjeKq-0007I1-9i for geb-bug-gnu-emacs@m.gmane.org; Mon, 12 May 2014 02:43:16 +0200 Original-Received: from localhost ([::1]:34790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjeKp-0006KF-OK for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 May 2014 20:43:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56201) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjeKh-0006Jz-NY for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:43:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WjeKc-0004Vp-Rp for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:43:07 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:42525) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WjeKc-0004Vl-Oa for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1WjeKc-0008JC-AU for bug-gnu-emacs@gnu.org; Sun, 11 May 2014 20:43:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alex Kosorukoff Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 12 May 2014 00:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 17467 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 17467-submit@debbugs.gnu.org id=B17467.139985534031888 (code B ref 17467); Mon, 12 May 2014 00:43:01 +0000 Original-Received: (at 17467) by debbugs.gnu.org; 12 May 2014 00:42:20 +0000 Original-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 Original-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 Original-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) Original-Received: by 10.182.240.131 with HTTP; Sun, 11 May 2014 17:41:48 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: E3q0HntCQEW552_O6vtCjUE7vNU 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:88947 Archived-At: --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--