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

[Alan Mackenzie]

Hello, Eli. 

On Thu, Jul 21, 2022 at 20:53:28 +0300, Eli Zaretskii wrote:
> > Date: Thu, 21 Jul 2022 17:37:19 +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.

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.

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

..  



> > > >                                        If you want to find the actual
> > > > +file loaded from, and you suspect if may really be a native compiled
> > > > +file, something like the following should help.  You need to know the
> > > > +name of a function which hasn't been advised, say @var{foo}, defined
> > > > +in the suspected native compiled file.  Then
> > > > +
> > > > +@lisp
> > > > +(let ((foo-fun (symbol-function #'FOO)))
> > > > +       (and foo-fun (subr-native-elisp-p foo-fun)
> > > > +            (native-comp-unit-file (subr-native-comp-unit foo-fun))))
> > > > +@end lisp
> > > > +
> > > > +@noindent
> > > > +will return either the name of the native compiled file defining
> > > > +@var{foo}, or @code{nil} if there is no such file.

> > > This is not a good way of documenting some technique in this manual.
> > > The way we describe such stuff is by documenting the functions a
> > > program needs to use, not by giving a random example which calls the
> > > functions without any documentation of the functions themselves.

> > OK.  But I think here could be an exception.  Describing the functions
> > separately on their own page will not help users to get the loaded file
> > name without a great deal of research.

> 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?  Would
it be better to write a new function incorporating the procedure, and
document that?

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

> > 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?  It generates
file names which might not name existing files.  It doesn't seem ideal
for the purpose.

> > > Also, native-comp-unit-file doesn't exist in a build without native
> > > compilation support, so some feature test is missing.

> > Do you mean a test in the TexInfo sources which would test whether it's
> > necessary to include that example in the finished manual?

> No, I mean a test in the @example code.  You want that snippet to be
> complete, so that readers could copy it into their programs, right?

Ah, I see.  Yes, you're right.

-- 
Alan Mackenzie (Nuremberg, Germany).