[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: |
Tue, 26 Jan 2010 23:25:06 -0500 |
Hi Stefan,
On Sun, Jan 24, 2010 at 10:23 PM, Stefan Monnier
<address@hidden> wrote:
> This is not removing ".el.gz" from the return value. This is removing
> it from the search.
You fist indicated that `locate-library' doesn't remove extensions.
Now you acknowledge that it does.
The locus of the removal is irrelevant in lieu of the fact that it is getting
removed from the return value and shouldn't be.
I pass a permissible non-nil value for NOSUFFIX and I get a non-sensical result.
This is an error.
> I still do not know what this would be used for. Could you explain the
> actual use case you're thinking of?
Assume I have the file "library.el.gz" in the directory "/home/mon/fnd-lib"
Right if i ask for the location of "library" I get:
(locate-library "libary" t '("/home/mon/fnd-lib"))
=> nil
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"
See my earlier posts (presumably as yet unread) for examples of `mapping' loops
which might take advantage of the proposed behavior.
Hint, look for the lisp with the keys:
`:booleans', `:paths-w-compress', `:paths-nocompress'
> 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".
Indeed.
> Coulod be. Couldn't blame them. Now that locate-file is available, I'd
> recommend they use that instead.
A file is not a library.
Which library file shall I ask to locate when I don't yet know which
library file
I am looking for?
IOW, why bother locating when you already know with specificity what
your looking for?
> What does this use case show?
I asked to kill a library, I maybe kill a file-name or maybe I kill a nil. Where
I do kill a file-name it is unspecified which file-name I killed.
> What's the problem with it?
The problem is that at best I kill an unspecific file name.
> Stripping the extension is not the issue. I asked to kill
> a library namestring.
> What is "a library namestring"?
A string that names the location of a library up to but not including that
library's extension.
IOW what you _should_ get when you want to know where a library lives but don't
want a filename.
Think Common Lisp's `directory-namestring', `enough-namestring',
`file-namestring', `host-namestring', `parse-namestring', `namestring', etc.
> 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 <=
- 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/27
- 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