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: Sat, 23 Jan 2010 20:39:07 -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 1264297170 12079 80.91.229.12 (24 Jan 2010 01:39:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Jan 2010 01:39:30 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 24 02:39:22 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 1NYrRe-0005X3-UB for ged-emacs-devel@m.gmane.org; Sun, 24 Jan 2010 02:39:19 +0100 Original-Received: from localhost ([127.0.0.1]:46824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYrRg-0006v6-4m for ged-emacs-devel@m.gmane.org; Sat, 23 Jan 2010 20:39:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NYrRa-0006uA-Vz for emacs-devel@gnu.org; Sat, 23 Jan 2010 20:39:15 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NYrRV-0006r3-El for emacs-devel@gnu.org; Sat, 23 Jan 2010 20:39:13 -0500 Original-Received: from [199.232.76.173] (port=60082 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NYrRV-0006r0-8G for emacs-devel@gnu.org; Sat, 23 Jan 2010 20:39:09 -0500 Original-Received: from mail-yw0-f177.google.com ([209.85.211.177]:53514) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NYrRU-0008Kh-E9 for emacs-devel@gnu.org; Sat, 23 Jan 2010 20:39:08 -0500 Original-Received: by ywh7 with SMTP id 7so2091473ywh.24 for ; Sat, 23 Jan 2010 17:39:07 -0800 (PST) Original-Received: by 10.150.183.15 with SMTP id g15mr6333485ybf.231.1264297147242; Sat, 23 Jan 2010 17:39:07 -0800 (PST) In-Reply-To: X-Google-Sender-Auth: 0bd61e992088dc48 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:120318 Archived-At: On Sat, Jan 23, 2010 at 6:23 AM, Stefan Monnier wrote: >> I make the same request: >> (locate-library "subr" t '("/home/mon/fnd-sbr")) > >> locate-library returns >> => "/home/mon/fnd-sbr/subr.gz" > > Thanks! Yes, this is a good example of a problematic case. I wish you > had started with it. Your welcome. I'll jump out of sequence this time lest you hit ye 'olde wall of verbosity too soon. ;) > >> 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 `---- Where `locate-library' returns with "subr.gz" in the former it does not return with "subr.el.gz" in the later. As both are relevant file-names of "subr", and as in other less extreme corner cases either of these might return, it is not unreasonable to assume that in the latter example above the ".el.gz" suffix has been pathologically ``removed'' - IOW, the file is there, it is a rationale return value, yet we don't get to see it. > Indeed, the docstring would need adjustment for > it. Not sure how best to do it. The cheap way would be to adjust docs for both `locate-library' and `load-library' by indicating that the default suffixes are: (".elc" ".elc.gz" ".el" ".el.gz" "" ".gz") e.g.: (append (get-load-suffixes) load-file-rep-suffixes) Except when NOSUFFIX is non-nil, in which case the default suffixes are: ("" ".gz") Knock yourself explaining that empty string after 2.5 double negatives :P You could punt as with `load-library's: ,---- | See Info node `(emacs)Lisp Libraries' for more details. `---- Or, do as with `locate-file's: ,---- | If suffixes is nil, it is equivalent to '(""). `---- IMO, the full suite of docs for the "lo.*-\\(file\\|library\\)" fncns and vars are suspect though b/c they conflate filenames with libraries. > Basically the compression extensions like ".gz" are treated as > "non-suffixes". In this case, the default compression extension ".gz" is the only extension. > Or maybe the code should be changed to not add the compression suffixes in > this case. 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). o In lieu of a potentially breaking change above, the addition of an optional SHOW-COMPRESSED arg which conditionally reveals the compression suffix if found. > 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. 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. Whether this _matters_ is prob. a maintenance consideration w/re code duplication vs. backwards compatibility. Again, see my quip about ffap's `ffap-locate-file' as one case in point... FWIW this is the (un)use(able) case that piqued my interest: (kill-new (locate-library "subr")) Stripping the extension is not the issue. I asked to kill a library namestring. > > Stefan > /s_P\