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: Sun, 24 Jan 2010 22:23:02 -0500 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1264389803 26388 80.91.229.12 (25 Jan 2010 03:23:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 25 Jan 2010 03:23:23 +0000 (UTC) Cc: emacs-devel@gnu.org To: MON KEY Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 25 04:23:15 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 1NZFXl-0002hZ-Hq for ged-emacs-devel@m.gmane.org; Mon, 25 Jan 2010 04:23:13 +0100 Original-Received: from localhost ([127.0.0.1]:60361 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZFXm-0007oC-2o for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2010 22:23:14 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NZFXg-0007nF-Ie for emacs-devel@gnu.org; Sun, 24 Jan 2010 22:23:08 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NZFXc-0007mH-5I for emacs-devel@gnu.org; Sun, 24 Jan 2010 22:23:08 -0500 Original-Received: from [199.232.76.173] (port=46083 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NZFXb-0007mE-Uj for emacs-devel@gnu.org; Sun, 24 Jan 2010 22:23:03 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.183]:35890 helo=ironport2-out.pppoe.ca) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NZFXb-0004Zs-Na for emacs-devel@gnu.org; Sun, 24 Jan 2010 22:23:03 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAKmdXEvO+LMp/2dsb2JhbACBRtQxhDsEik4 X-IronPort-AV: E=Sophos;i="4.49,337,1262581200"; d="scan'208";a="54475131" Original-Received: from 206-248-179-41.dsl.teksavvy.com (HELO ceviche.home) ([206.248.179.41]) by ironport2-out.pppoe.ca with ESMTP; 24 Jan 2010 22:23:03 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id D0B7EB4235; Sun, 24 Jan 2010 22:23:02 -0500 (EST) In-Reply-To: (MON KEY's message of "Sat, 23 Jan 2010 20:39:07 -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:120334 Archived-At: >>> Except ".el.gz" right? >> Again, please give me a relevant example. > As per the examples provided above: > ,---- > | Now, assume I have only subr.el and subr.gz in the same directory. > | > | locate-library returns > | => "/home/mon/fnd-sbr/subr.gz" > | > | {...} > | > | Now, assume I have only of subr.el.gz in same directory? > | (locate-library "subr" t '("/home/mon/fnd-sbr")) > | => nil > `---- This is not removing ".el.gz" from the return value. This is removing it from the search. > Assuming the compression suffix can be found correctly in all cases > there are more situations where compression suffixe are wanted than > not. However, this is not the case now. And, so long as Emacs can be > built with compressed libraries, those so suffixed _will_ be > sought. Hence my proposal(s): > o That NOSUFFIX be allowed to return a non-suffixed library name-string > conditioned on the type of argument given (which buys you bckw-compat). I still do not know what this would be used for. Could you explain the actual use case you're thinking of? >> I can't remember enough of why the code is doing it now: maybe it's >> simple accidental consequence of the implementation, or maybe there's >> an actual use case for which it matters. > I'm not sure of which use case you are referring. 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". > My impression is that the use cases don't arise that often (or aren't > reported) because users have avoided using `locate-library' in > these situations. Coulod be. Couldn't blame them. Now that locate-file is available, I'd recommend they use that instead. > FWIW this is the (un)use(able) case that piqued my interest: > (kill-new (locate-library "subr")) What does this use case show? What's the problem with it? > Stripping the extension is not the issue. I asked to kill > a library namestring. What is "a library namestring"? Stefan