From: Alex Kosorukoff <alex@3form.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 17467 <17467@debbugs.gnu.org>
Subject: bug#17467: 24.3; locate-library returning spurious path
Date: Thu, 15 May 2014 16:57:27 -0700 [thread overview]
Message-ID: <CAHD9_tRUbrJ_U2Cgt=3u-1RSXPiEzrhvJVWJH-t7fayY3reCTQ@mail.gmail.com> (raw)
In-Reply-To: <jwvha4qltsr.fsf-monnier+emacsbugs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2244 bytes --]
On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier
<monnier@iro.umontreal.ca>wrote:
> > locate-library incorrectly generates a set of suffixes to extend the
> > base library name (".elc" ".elc.gz" ".el" ".el.gz" "" ".gz"), while it
> > should be just (".elc" ".elc.gz" ".el" ".el.gz") when nosuffix is
> > nil.
>
> FWIW, this simply reflects what `load' does, so changing it in
> `locate-library' would mean that it doesn't do what `load' does, which
> I would count as a bug.
>
I agree with you that locate library should do what load does.
> The main issue I see is that `load' includes a `must-suffix' argument
> which provides the behavior you're looking for (and which is used by
> `require') whereas locate-library doesn't provide it.
>
> > This leads to spurious paths found, like name.gz. I found
> > this issue because (locate-library "tramp") was returning
> > "/home/alex/.emacs.d/trump" not "../lisp/net/trum.elc". The workaround
> > is (locate-file "tramp" load-path (get-load-suffixes))
>
> IIUC the problem you had was with `load' rather than with
> `locate-library', so I think what this boils down to is that the `load'
> that looks for `trump' should be changed to provide `must-suffix'.
> WDYT?
>
In fact, I was looking for a function that would locate library and return
the path to it, so I could compile the explicit path into .elc file that
will avoid searching load-path and save time when it is run. locate-library
seems like a perfect tool for this purpose, but turned out to be not as
useful as it sounds because it is not currently capable of correctly
reproducing search behavior of load or require. As a result, I switched to
locate-file. This currently seems to be the only reliable way to find
correct paths to libraries. I think we could make locate-library more
useful by extending it in one of two possible ways. It can either accept
symbol argument as well as string and behave exactly like require does in
this case (currently it will just fail with error if given a symbol). An
alternative way is to add an optional must-suffix argument to make it
consistent with load. Both ways will keep it backward compatible and will
allow it to emulate the logic of both load and require.
>
>
> Stefan
>
[-- Attachment #2: Type: text/html, Size: 3296 bytes --]
prev parent reply other threads:[~2014-05-15 23:57 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-11 16:06 bug#17467: 24.3; locate-library returning spurious path Alex Kosorukoff
2014-05-11 17:03 ` Eli Zaretskii
2014-05-11 17:38 ` Alex Kosorukoff
2014-05-11 17:46 ` Eli Zaretskii
2014-05-11 17:53 ` Alex Kosorukoff
2014-05-11 18:10 ` Eli Zaretskii
2014-05-11 18:55 ` Alex Kosorukoff
2014-05-11 22:55 ` Stefan Monnier
2014-05-12 0:41 ` Alex Kosorukoff
2014-05-11 17:37 ` Glenn Morris
2014-05-11 17:43 ` Alex Kosorukoff
2014-05-11 19:50 ` Stefan Monnier
2014-05-11 20:45 ` Alex Kosorukoff
2014-05-11 21:00 ` Alex Kosorukoff
2014-05-11 21:19 ` Glenn Morris
2014-05-11 22:31 ` Alex Kosorukoff
2014-05-11 21:56 ` Stefan Monnier
2014-05-12 0:20 ` Alex Kosorukoff
2014-05-12 0:32 ` Glenn Morris
2014-05-12 1:35 ` Alex Kosorukoff
2014-05-12 2:02 ` Alex Kosorukoff
2014-05-12 2:18 ` Stefan Monnier
2014-05-12 4:36 ` Alex Kosorukoff
2014-05-12 6:39 ` Stefan Monnier
2014-05-12 17:46 ` Alex Kosorukoff
2020-08-25 10:39 ` Lars Ingebrigtsen
2020-08-25 14:22 ` Stefan Monnier
2020-08-25 14:25 ` Lars Ingebrigtsen
2020-10-13 1:41 ` Lars Ingebrigtsen
2014-05-15 19:39 ` Stefan Monnier
2014-05-15 23:57 ` Alex Kosorukoff [this message]
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHD9_tRUbrJ_U2Cgt=3u-1RSXPiEzrhvJVWJH-t7fayY3reCTQ@mail.gmail.com' \
--to=alex@3form.com \
--cc=17467@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.