[Top][All Lists]
[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: |
Wed, 27 Jan 2010 20:09:31 -0500 |
On Wed, Jan 27, 2010 at 9:55 AM, Stefan Monnier
<address@hidden> 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\
- locate-library, the NOSUFFIX arg and a [PATCH], MON KEY, 2010/01/19
- Re: locate-library, the NOSUFFIX arg and a [PATCH], Stefan Monnier, 2010/01/21
- Re: locate-library, the NOSUFFIX arg and a [PATCH], MON KEY, 2010/01/21
- Re: locate-library, the NOSUFFIX arg and a [PATCH], Stefan Monnier, 2010/01/22
- Re: locate-library, the NOSUFFIX arg and a [PATCH], MON KEY, 2010/01/22
- Re: locate-library, the NOSUFFIX arg and a [PATCH], Stefan Monnier, 2010/01/23
- Re: locate-library, the NOSUFFIX arg and a [PATCH], MON KEY, 2010/01/23
- Re: locate-library, the NOSUFFIX arg and a [PATCH], Stefan Monnier, 2010/01/24
- Re: locate-library, the NOSUFFIX arg and a [PATCH], MON KEY, 2010/01/26
- Re: locate-library, the NOSUFFIX arg and a [PATCH], Stefan Monnier, 2010/01/27
- Re: locate-library, the NOSUFFIX arg and a [PATCH],
MON KEY <=
- Re: locate-library, the NOSUFFIX arg and a [PATCH], Stefan Monnier, 2010/01/27
- Re: locate-library, the NOSUFFIX arg and a [PATCH], MON KEY, 2010/01/28