Re: How does one find out what file a library has been loaded from?

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> If you want to do that, just knowing what was actually loaded won't
>> help you, because you will have to actually _prevent_ Emacs from
>> loading the .eln files, and that's not easy and currently not really
>> supported on the user level, at least not conveniently.  So you will
>> have to rename directories and stuff, and once you are there,
>> load-history is the last thing you will worry about, because you will
>> know in advance what Emacs loads, as you force it to do that yourself.
>
> Yes.  I don't think this is good.

AFAIK we all agree on that.  Complaining about it won't help.

>> Andrea gave you one way; I gave another.  None of them is difficult,
>> please don't exaggerate.
>
> There's nothing particularly difficult in any of Emacs if you're prepared
> to put in the time and energy to find out about it.  The method Andrea
> gave is not easy to remember, and (having looked for it) is not to be
> found in the Elisp manual.  It involves the obscure undocumented
> abstraction "native compilation unit".  But it is certainly a lot better
> than no method at all.

Designing a better method will need to know what is the intended use.
IIUC your main purpose is to check whether you're running source code,
byte-code, or native code, and for that you shouldn't look for a file
name and infer the result from the file name (which could be
misleading: a .elc can contain non-byte code, and a .eln can contain
byte-code (and source code as well)) but instead you're better off
checking with `byte-code-function-p` and `subrp` (or
`subr-native-elisp-p`).

> These other ways jar horribly with what used to be the philosophy (I know
> you don't like the word) of Emacs, of being open and honest with users.

Hi Alan.  I'm Stefan, and this is Eli.  The same guys you've known for,
what, 20 years?  It's not like we changed philosophy along the way.
As the email to which you replied explained it's just that maintaining
backward compatibility prevented us from making the information
available in "the obvious way".

The info is still very much available out in the open, tho.
And we're still interested in figuring out *how* to make it more
easily available.  Andrea did a great job integrating the native
compiler while trying to preserve compatibility.  But it's not like this
is the end of the story: we can and should definitely improve it (maybe
starting with `describe-function`).

> I shouldn't have to use obscure workarounds to discover what should be
> open and obvious.

So, please help us.  You're venting your frustration, but we suffer from
those issues (rather than benefit from them) just like you do.

> I will set about amending the doc string and manual entry for
> load-history.

Thanks,


        Stefan