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

[Eli Zaretskii <eliz@gnu.org>]

> 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 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.

> > 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.

> 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?

> > 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.

> 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.
> 
> > If you cannot figure it out from the code, feel free to ask questions.
> 
> 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.

> > > 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.

> 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.  What exactly are you trying to accomplish and why?  What is
the data from which you start and what is the data you want to obtain
as result?  In particular, is the starting point a function or a file
name? or something else entirely?