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

[MON KEY <monkey@sandpframing.com>]

On Wed, Jan 27, 2010 at 9:55 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> I see that my explanation still left room for confusion:

Stefan, I'm not the dimmest bulb in the drawer; This is your third attempt at
rephrasing the existing functionality.

>
> I hope this is more clear now.  These two are completely different.
> NOSUFFIX does what the case (2) does, not what the case (1) does.

Thank you for this explanation.

Following is a rhetorical question; but if it helps you to see the problem then
by all means feel free to continue with the enumeratiation. Why won't it return
for "/my/bar/foo.el" either but it will return for "/my/bar/foo.gz"? e.g.

 (locate-library "foo" t '("/my/bar"))

>> 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"
>
> I don't follow you.  If you want that, then why do you specify a non-nil
> value for NOSUFFIX??

Look closely. The fourth arg of the second example is using the proposed
SHOW-COMPRESSED. Which says, "Show me the file name sans extension unless
library name is a compressed file in which case let me know by showing me the
extension.

>
> That's irrelevant.  `locate-library' returns a file name, not a library name.
>

Not entirely irrelevant.  What is a library name then?

If there is a distinction between a library and a file it is not clear.

How exactly should one specify a library name for the LIBRARY arg to
locate-library if this is not the same object(s) as a file name?

Please understand, my intention is not to be pedantic. It is important
that if there is a distinction between the two that it be specified.

>> I asked to kill a library,
>
> No, you didn't.  Check the docstring of locate-library:
>
>  "Show the precise file name of Emacs library LIBRARY."
>
> I.e. it returns a file name, so you asked to "kill" a file name.
>

Hrmmm. Precisely what is, "the precise file name of an Emacs library"?

>
> I have no idea what kind of "specification" you'd expect other than the
> one you currently get from locate-library's docstring.
>

Agreed. Hence the conundrum.

>
> Then don't do that.
> Seen from here, it looks like you're using
> locate-library to do something else than what it does;

Indeed. It is obviously pathological (as was indicated in the orignial context).

> although I'm not 100% positive it's the case because I don't really know what
> it is you want (kill-new (locate-library "subr")) to do.
>

This was provided as an example where I found the expected behavior surprising.

A better example use-case for the proposed patch might be where one would like
to generate a list from which one could inform/extend/override
`emacs-lisp-file-regexp', `byte-compile-dest-file', `declare-function',
`check-declare-directory', `byte-compiler-base-file-name', etc. to
select/operate on a library per case based conditionals of the list elements.

>
> Ah, now I see.  This notion of "library name stripped of its extension"
> is not one that Emacs uses much, AFAIK.

You say this is an esoteric feature but if it does indeed exist please tell me
its name maybe I can use it to scratch this itch...

It is a notion used all the time just from the other direction, i.e. by
stripping instead of adding it back on. Likewise, it is a notion which will be
required more with increased package support and distributed/versioned code and
is IMHO a likely eventuality required in each arena. This NOSUFFIX problem is
compounded when there are duplicate library's across multiple dir
hierarchies. FWIW you have a fully fleshed abstraction for objects
now... This is
exactly the type of feature they are great at abstracting.

>
> Why do you want it without the extension?
>

Why wouldn't I? :)

I do do want the extension, but I would prefer to set the conditions upon which
the extensions are made available.

> Depending on this question, we may be able to determine things like
> whether you'd like (your-locate-library "foo.el" t) to return "/bar/foo"
> or "/bar/foo.el".

Exactly.

>
> Since locate-library returns a filename and you "don't want a filename",
> it's no wonder you don't like the return value of locate-library.
>

Don't twist me off axis.
What I don't want is a file name where a library name is requested.

To the extent that `locate-library' is essentially obsoleted by `locate-file'
what is the big deal changing it ;-)

>
>        Stefan

/s_P\