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

[Eli Zaretskii]

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

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

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

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

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