From: Stefan Monnier <monnier@iro.umontreal.ca>
To: MON KEY <monkey@sandpframing.com>
Cc: emacs-devel@gnu.org
Subject: Re: locate-library, the NOSUFFIX arg and a [PATCH]
Date: Sun, 24 Jan 2010 22:23:02 -0500 [thread overview]
Message-ID: <jwv7hr66fo0.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <d2afcfda1001231739p4f4ba8eexe415e4986ded5242@mail.gmail.com> (MON KEY's message of "Sat, 23 Jan 2010 20:39:07 -0500")
>>> 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
next prev parent reply other threads:[~2010-01-25 3:23 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-19 22:28 locate-library, the NOSUFFIX arg and a [PATCH] MON KEY
2010-01-21 14:08 ` Stefan Monnier
2010-01-21 23:58 ` MON KEY
2010-01-22 15:18 ` Stefan Monnier
2010-01-23 2:10 ` MON KEY
2010-01-23 11:23 ` Stefan Monnier
2010-01-24 1:39 ` MON KEY
2010-01-25 3:23 ` Stefan Monnier [this message]
2010-01-27 4:25 ` MON KEY
2010-01-27 14:55 ` Stefan Monnier
2010-01-28 1:09 ` MON KEY
2010-01-28 2:46 ` Stefan Monnier
2010-01-29 2:55 ` MON KEY
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv7hr66fo0.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=monkey@sandpframing.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).