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

[Alan Mackenzie <acm@muc.de>]

Hello, Eli.

On Thu, Jul 21, 2022 at 09:13:03 +0300, Eli Zaretskii wrote:
> > Date: Wed, 20 Jul 2022 20:34:05 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > Here's a first preliminary effort at amending loading.texi:

> Thanks, but it "needs work"(TM).

> >  @defun symbol-file symbol &optional type
> > -This function returns the name of the file that defined @var{symbol}.
> > -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 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.  The current text is not accurate.  The situation
it is describing is vague and confusing.

Would this strategy be an improvement: "This function returns a file
name.  When the file from which the function was loaded was a source
file or byte compiled file .......  When that file was a native compiled
file ......."?

[ .... ]

> > -  The command @code{eval-region} updates @code{load-history}, but does so
> > -by adding the symbols defined to the element for the file being visited,
> > -rather than replacing that element.  @xref{Eval}.
> > +@anchor{eln files} For backwards compatibility, @code{load-history}
> > +stores and @code{symbol-file} returns the name of a notional byte
> > +compiled @file{.elc} file in the same directory as its source file
> > +when the real file loaded from is a natively compiled file elsewhere.
> > +This @file{.elc} file may or may not actually exist.  For other files,
> > +their absolute file names are used.

> This last sentence is "out of the blue": what "other files"?

Files other than "a natively compiled file elsewhere".  But I'll admit it
doesn't read well, yet.

> The text should also have a cross-reference to where native
> compilation is described in the manual.

OK.

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

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

> Finally, "FOO" is not how we refer to a meta-syntactic variable in the
> manual: we use @var{foo} instead.

Sorry.  I thought that @var{FOO} would not work in @lisp, but I tried it
out and it does work.  I've already corrected it.

> > +The command @code{eval-region} updates @code{load-history}, but does
> > +so by adding the symbols defined to the element for the file being
> > +visited, rather than replacing that element.  @xref{Eval}.

> This part should be before the text which explains the issues with
> loading *.eln files.

OK, that's easily fixed.

-- 
Alan Mackenzie (Nuremberg, Germany).