unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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




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