bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17467: 24.3; locate-library returning spurious path


From: Alex Kosorukoff
Subject: bug#17467: 24.3; locate-library returning spurious path
Date: Thu, 15 May 2014 16:57:27 -0700

On Thu, May 15, 2014 at 12:39 PM, Stefan Monnier <address@hidden> 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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]