From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: locate-library, the NOSUFFIX arg and a [PATCH] Date: Wed, 27 Jan 2010 09:55:50 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1264604964 4817 80.91.229.12 (27 Jan 2010 15:09:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jan 2010 15:09:24 +0000 (UTC) Cc: emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 27 16:09:20 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Na9Sp-0005uZ-1D for ged-emacs-devel@m.gmane.org; Wed, 27 Jan 2010 16:05:51 +0100 Original-Received: from localhost ([127.0.0.1]:59323 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Na9LP-0000eF-6n for ged-emacs-devel@m.gmane.org; Wed, 27 Jan 2010 09:58:11 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Na9JD-0008Ax-Jn for emacs-devel@gnu.org; Wed, 27 Jan 2010 09:55:55 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Na9J9-00089F-Vy for emacs-devel@gnu.org; Wed, 27 Jan 2010 09:55:55 -0500 Original-Received: from [199.232.76.173] (port=42239 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Na9J9-000899-Mi for emacs-devel@gnu.org; Wed, 27 Jan 2010 09:55:51 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:34766 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Na9J9-00064m-Bk for emacs-devel@gnu.org; Wed, 27 Jan 2010 09:55:51 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArUEAFfiX0tFpaAe/2dsb2JhbACBNNZohDkEilE X-IronPort-AV: E=Sophos;i="4.49,354,1262581200"; d="scan'208";a="54667443" Original-Received: from 69-165-160-30.dsl.teksavvy.com (HELO pastel.home) ([69.165.160.30]) by ironport2-out.pppoe.ca with ESMTP; 27 Jan 2010 09:55:50 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 0CDEE88D6; Wed, 27 Jan 2010 09:55:50 -0500 (EST) In-Reply-To: (MON KEY's message of "Tue, 26 Jan 2010 23:25:06 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:120507 Archived-At: >> This is not removing ".el.gz" from the return value. This is removing >> it from the search. > You fist indicated that `locate-library' doesn't remove extensions. > Now you acknowledge that it does. I see that my explanation still left room for confusion: 1- =ABremoving ".el.gz" from the return value=BB means that instead of returning "/bar/foo.el.gz" it would return "/bar/foo". 2- =ABremoving it from the search=BB means that locate-library will not look for files that end in ".el.gz" at all. I hope this is more clear now. These two are completely different. NOSUFFIX does what the case (2) does, not what the case (1) does. >> I still do not know what this would be used for. Could you explain the >> actual use case you're thinking of? > Assume I have the file "library.el.gz" in the directory "/home/mon/fnd-li= b" > Right if i ask for the location of "library" I get: > (locate-library "libary" t '("/home/mon/fnd-lib")) > =3D> nil > It would be really great to ask with: > (locate-library "libary" t '("/home/mon/fnd-lib") t) > and get: > =3D> "/home/mon/fnd-lib/library.el.gz" I don't follow you. If you want that, then why do you specify a non-nil value for NOSUFFIX?? >> Could be. Couldn't blame them. Now that locate-file is available, I'd >> recommend they use that instead. > A file is not a library. That's irrelevant. `locate-library' returns a file name, not a library nam= e. >>> (kill-new (locate-library "subr")) >> What does this use case show? > I asked to kill a library, No, you didn't. Check the docstring of locate-library: "Show the precise file name of Emacs library LIBRARY." I.e. it returns a file name, so you asked to "kill" a file name. > I maybe kill a file-name or maybe I kill a nil. Where I do kill > a file-name it is unspecified which file-name I killed. I have no idea what kind of "specification" you'd expect other than the one you currently get from locate-library's docstring. >> What's the problem with it? > The problem is that at best I kill an unspecific file name. Then don't do that. Seen from here, it looks like you're using locate-library to do something else than what it does; although I'm not 100% positive it's the case because I don't really know what it is you want (kill-new (locate-library "subr")) to do. >> Stripping the extension is not the issue. I asked to kill >> a library namestring. >> What is "a library namestring"? > A string that names the location of a library up to but not including that > library's extension. Ah, now I see. This notion of "library name stripped of its extension" is not one that Emacs uses much, AFAIK. Why do you want it without the extension? Depending on this question, we may be able to determine things like whether you'd like (your-locate-library "foo.el" t) to return "/bar/foo" or "/bar/foo.el". > IOW what you _should_ get when you want to know where a library lives > but don't want a filename. Since locate-library returns a filename and you "don't want a filename", it's no wonder you don't like the return value of locate-library. Stefan