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: Stefan Monnier
Subject: Re: locate-library, the NOSUFFIX arg and a [PATCH]
Date: Sun, 24 Jan 2010 22:23:02 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

>>> 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




reply via email to

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