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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Sat, Jul 23, 2022 at 13:11:54 +0300, Eli Zaretskii wrote:
> > Date: Thu, 21 Jul 2022 20:39:48 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > > > +This function returns a file name associated with the file that
> > > > > > +defined @var{symbol} (@pxref{eln files}).  If @var{type} is
> > > > > > +@code{nil}, then any kind of definition is acceptable.  If @var{type}
> > > > > > +is @code{defun}, @code{defvar}, or @code{defface}, that specifies
> > > > > > +function definition, variable definition, or face definition only.

> > > > > This change is for the worse: it introduces a vague and confusing
> > > > > notion of "file name associated with the file that defines" a symbol.
> > > > > This should be removed from the patch, as it doesn't add any useful
> > > > > information, just muddies the waters.

> > > > It's accurate, though.

> > > No, it isn't accurate, because it doesn't say anything definitive.

> > It says (or implies) there is nothing definitive to say.

> But that is not true.  The original text says something definitive and
> useful.  Adding information to it should NOT lose any of the
> information that was there to begin with, because that information
> still correct and not obsolete.

I just don't understand you saying that the information is still correct.
In about "half" the cases, when a .eln file has been loaded, the current
text in the Elisp manual and load-history doc string is no longer
correct.  The file given in load-history is not the file that was loaded
into Emacs.

> > I think it says as much as you can say about the connection between the
> > name of the loaded file and the file name recorded in load-history in a
> > single sentence.

> It is never a good thing to say "as much as you can say" if it leaves
> the reader less wise.

It is proving difficult to amend that text to make it accurate, while not
confusing its reader.

> > > What exactly did you want to say here, and why?  (See, I didn't even
> > > understand you intention, from reading that text.)

> > That there exists such a relationship between the file and the recorded
> > file name, but avoiding the falsehood that the file name is (in general)
> > the name of that file.

> Then TRT is to say what happens normally, and then add the description
> of what happens in exceptional cases, including the description of
> when the exceptions happen.

We don't have exceptional cases here.  We have two normal cases, one
where we load a .elc file, the other where we load a .eln file.  I think
both somehow have to be described as normal cases.

> > As an example there is a relationship between

> >     (i)
> >     /home/acm/emacs/emacs.git/sub-master-5/lisp/progmodes/cc-engine.elc,
> >     the file name recorded in load-history;

> > and

> >     (ii)
> >     "/home/acm/.emacs.d/eln-cache/29.0.50-850ec122/cc-engine-fae36ae5-5d7a60de.eln",
> >     the loaded file

> What does symbol-file has to do with any such "relationship"?  All you
> want to _add_ is that in an Emacs with native-compilation, loading a
> .elc file can eventually load the corresponding .eln file instead.  So
> why not just say that?

Maybe I'll try that.  One reason not to say it is that we intend the .eln
case to become the more common case, don't we?  Also, we really ought to
describe what /home/acm/..../cc-engine.elc _is_ in the documentation.
There's no guarantee that that file exists.

> > > You can describe them, and then show the example.  Or fill in the
> > > blanks as part of the functions' description.

> > Why is giving the code snippet, as I proposed, not a good thing?

> Because it uses functions not described in the manual.

OK.

> > Would it be better to write a new function incorporating the
> > procedure, and document that?

> In principle, yes.  But we need to discuss first what would that
> function be.  See below.

> > > > I've tried out this recipe and it works, but I don't yet know
> > > > what these native-comp-unit functions are for, what they do in
> > > > any detail, or even what a compilation-unit is.  The functions
> > > > are not already in the Elisp manual, and their doc strings are
> > > > somewhat terse.

> > I can figure out just about anything from Emacs's code (apart from the
> > philosophical things), but there are only so many hours in a day.

> You are splitting hair, but let me rephrase: if you cannot figure it
> out in some reasonable amount of time, feel free to ask.

All right.  I think it would be useful to tie down the abstraction
"native compilation unit".  It is probably something quite simple, yet
there is no "unit" in the Elisp manual index.  What is a "native
compilation unit"?

> > > > I still think it would be a good thing to be able to get the name
> > > > of an actual load file from the .elc name stored in load-history
> > > > without having to go through the intermediate step of knowing a
> > > > function name defined by it.

> > > Did you try comp-el-to-eln-filename?

> > No.  How could I have known that such a function exists?

> I just told you about it.  I told you about it not as an accusation,
> but as a way to help you find the best way of solving your problem.

OK, thanks.  But I still don't think I could have found out the existence
of this function without asing "are there any relevant
functions/variables to what I'm trying to do?".

> > It generates file names which might not name existing files.  It
> > doesn't seem ideal for the purpose.

> Then I think you should describe the purpose better and in more
> detail.

I simply wish to know the file from which a function has been loaded, or
the loaded file corresponding to some source file.  I would like to know
whether this file is a source file, a .elc, or a .eln.

> What exactly are you trying to accomplish and why?

There are lots of reasons I might want to know the loaded file, some of
which have already come up in the thread.  I might want to be sure I've
built Emacs with native compilation.  I might be interested in
benchmarking or RAM occupancy.  I might wish to firm up my mental model
of my Emacs (this indeed has been the case for me).

> What is the data from which you start and what is the data you want to
> obtain as result?

The name of a source file or function, and the name of the matching file
which was loaded.

> In particular, is the starting point a function or a file name? or
> something else entirely?

Either a function or a file name.

-- 
Alan Mackenzie (Nuremberg, Germany).