From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: MON KEY Newsgroups: gmane.emacs.devel Subject: Re: locate-library, the NOSUFFIX arg and a [PATCH] Date: Tue, 26 Jan 2010 23:25:06 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1264566332 19948 80.91.229.12 (27 Jan 2010 04:25:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 27 Jan 2010 04:25:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 27 05:25:24 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.50) id 1NZzSz-0000E6-0f for ged-emacs-devel@m.gmane.org; Wed, 27 Jan 2010 05:25:21 +0100 Original-Received: from localhost ([127.0.0.1]:34054 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZzSx-0002XF-Jz for ged-emacs-devel@m.gmane.org; Tue, 26 Jan 2010 23:25:19 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZzSs-0002Wu-PC for emacs-devel@gnu.org; Tue, 26 Jan 2010 23:25:14 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZzSn-0002WZ-71 for emacs-devel@gnu.org; Tue, 26 Jan 2010 23:25:13 -0500 Original-Received: from [199.232.76.173] (port=49186 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZzSn-0002WW-1b for emacs-devel@gnu.org; Tue, 26 Jan 2010 23:25:09 -0500 Original-Received: from mail-yx0-f177.google.com ([209.85.210.177]:48445) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZzSm-0004wk-T0 for emacs-devel@gnu.org; Tue, 26 Jan 2010 23:25:09 -0500 Original-Received: by yxe7 with SMTP id 7so4307557yxe.25 for ; Tue, 26 Jan 2010 20:25:07 -0800 (PST) Original-Received: by 10.150.252.3 with SMTP id z3mr11924992ybh.62.1264566306906; Tue, 26 Jan 2010 20:25:06 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 8cd4e8f0b29ee31c X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) 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:120478 Archived-At: Hi Stefan, On Sun, Jan 24, 2010 at 10:23 PM, Stefan Monnier wrote: > 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. The locus of the removal is irrelevant in lieu of the fact that it is getting removed from the return value and shouldn't be. I pass a permissible non-nil value for NOSUFFIX and I get a non-sensical result. This is an error. > 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-lib" Right if i ask for the location of "library" I get: (locate-library "libary" t '("/home/mon/fnd-lib")) => nil It would be really great to ask with: (locate-library "libary" t '("/home/mon/fnd-lib") t) and get: => "/home/mon/fnd-lib/library.el.gz" See my earlier posts (presumably as yet unread) for examples of `mapping' loops which might take advantage of the proposed behavior. Hint, look for the lisp with the keys: `:booleans', `:paths-w-compress', `:paths-nocompress' > As mentioned, I don't know them. But they'd look like a situation where > it would be problematic if (locate-library "foo" t) did not find > "/bar/foo.gz". Indeed. > Coulod be. Couldn't blame them. Now that locate-file is available, I'd > recommend they use that instead. A file is not a library. Which library file shall I ask to locate when I don't yet know which library file I am looking for? IOW, why bother locating when you already know with specificity what your looking for? > What does this use case show? I asked to kill a library, 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. > What's the problem with it? The problem is that at best I kill an unspecific file name. > 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. IOW what you _should_ get when you want to know where a library lives but don't want a filename. Think Common Lisp's `directory-namestring', `enough-namestring', `file-namestring', `host-namestring', `parse-namestring', `namestring', etc. > Stefan /s_P\