emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: locate-library, the NOSUFFIX arg and a [PATCH]


From: MON KEY
Subject: Re: locate-library, the NOSUFFIX arg and a [PATCH]
Date: Sat, 23 Jan 2010 20:39:07 -0500

On Sat, Jan 23, 2010 at 6:23 AM, Stefan Monnier
<address@hidden> 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\




reply via email to

[Prev in Thread] Current Thread [Next in Thread]