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

[Alan Mackenzie]

Hello, Eli.

On Tue, Jul 19, 2022 at 18:50:00 +0300, Eli Zaretskii wrote:
> > Date: Tue, 19 Jul 2022 15:01:12 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > What do you like to find? whether it was loaded from cc-engine.elc or
> > > cc-engine-XXXXXX.eln?

> > Exactly that, yes.

> > > If so, why does it matter?

[ .... ]

> > A further point is that Emacs should not deceive its users.

> It doesn't.

It most assuredly does.  The doc string for load-history says that 

    FILE-NAME is the name of a file that has been loaded into Emacs.

This is untrue.  What is true is that it is the "NOTIONAL" file that has
been loaded into Emacs.... or that it is the name of the source file
with a "c" appended.

When the function of load-history was changed, why was its doc string
not amended?  (Yes, I am volunteering to take on this task.)

> > There's the point that if you're doing benchmark timings, the
> > results are meaningless if you don't know what you're timing.

> You are timing compiled Lisp code.  How exactly was it compiled
> shouldn't matter _in_principle_, ....

You might well want to compare the speed of byte compiled code with the
same source native compiled, as many of us have already attempted to do.

> .... exactly as you don't have any easy way of knowing what version of
> byte-compiler and byte-optimizer was used to produce a .elc file --
> and the differences can be significant.

Eli, that's .....  No, I won't write it.

> If you do need to make this kind of distinctions, you have to use
> "different means".

Or do you mean "difficult means"?  Let me propose that there should be
an easy way of finding this out.

> Like disassembly of the byte-code or looking if cc-engine-XXXXXX.eln
> file is in your eln-cache, or using "C-h f" on some function from
> cc-engine, where Emacs will tell you whether it's byte-compiled or
> natively-compiled (you can also use subr-native-elisp-p directly if
> you want).

I don't want this.

It is clear that load-history no longer supports all its use cases.
Andrea has reported that trying to update it lead to too many problems.

So, how about a new additional variable called something like
load-file-history which would be like load-history, just it would store
the name of the source file (if known) as well as the name of the loaded
file?  In time (?10 years), load-history could be deprecated and
eventually superseded.

Or, less dramatically, an alist with the notional name in entries' cars,
and the actual loaded file name in the cdrs?  With this, it would be
trivial to find the loaded file name from the information in
load-history.

-- 
Alan Mackenzie (Nuremberg, Germany).