[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alan Mackenzie
Subject: Re: How does one find out what file a library has been loaded from?
Date: Wed, 20 Jul 2022 11:47:11 +0000

Hello, Eli.

On Tue, Jul 19, 2022 at 22:13:53 +0300, Eli Zaretskii wrote:
> > Date: Tue, 19 Jul 2022 17:07:09 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

> > > > A further point is that Emacs should not deceive its users.

> > > It doesn't.

> > It most assuredly does.  The doc string for load-history says that 

> >     FILE-NAME is the name of a file that has been loaded into Emacs.

> > This is untrue.

> Not really (please take a good look at what the code actually does).

If it loads a .eln file, and says it has loaded a .elc file, that is an
untruth.  Not a "sort of not quite true", but a blatant untruth.  I had a
look at the relevant code in lread.c some while ago.

> But if you are bothered by that detail, I'm okay with having a note
> there regarding *.eln files.  (Somehow, I'm not sure you will settle
> for that.)

I will write a patch for the doc string and another for the Elisp manual.
I'm not happy with the state of things, but will probably have to accept

> > > You are timing compiled Lisp code.  How exactly was it compiled
> > > shouldn't matter _in_principle_, ....

> > You might well want to compare the speed of byte compiled code with
> > the same source native compiled, as many of us have already attempted
> > to do.

> If you want to do that, just knowing what was actually loaded won't
> help you, because you will have to actually _prevent_ Emacs from
> loading the .eln files, and that's not easy and currently not really
> supported on the user level, at least not conveniently.  So you will
> have to rename directories and stuff, and once you are there,
> load-history is the last thing you will worry about, because you will
> know in advance what Emacs loads, as you force it to do that yourself.

Yes.  I don't think this is good.  But I suspect it's my own fault for
not paying attention to the emacs-devel threads about these things a year
or two ago.  That you input M-x load-file RET ~/foo.elc RET, and get a
different file loaded instead doesn't strike me as at all good.

> > Or do you mean "difficult means"?  Let me propose that there should be
> > an easy way of finding this out.

> Andrea gave you one way; I gave another.  None of them is difficult,
> please don't exaggerate.

There's nothing particularly difficult in any of Emacs if you're prepared
to put in the time and energy to find out about it.  The method Andrea
gave is not easy to remember, and (having looked for it) is not to be
found in the Elisp manual.  It involves the obscure undocumented
abstraction "native compilation unit".  But it is certainly a lot better
than no method at all.

> > It is clear that load-history no longer supports all its use cases.
> > Andrea has reported that trying to update it lead to too many problems.

> Yes, and therefore we won't change load-history any time soon.  Please
> use the other ways that were proposed, even if you for some reason I
> cannot understand don't like them.

These other ways jar horribly with what used to be the philosophy (I know
you don't like the word) of Emacs, of being open and honest with users.
I shouldn't have to use obscure workarounds to discover what should be
open and obvious.

> > So, how about a new additional variable called something like
> > load-file-history which would be like load-history, just it would
> > store the name of the source file (if known) as well as the name of
> > the loaded file?

> No, we won't have that.  It isn't needed, from my POV, and having yet
> another load-related path list will complicate the part of Emacs that
> is already mind-boggling.

> Again, you have been pointed to two ways of getting the information
> you want, and that is more than enough for a corner use case such as
> this one.

I will set about amending the doc string and manual entry for

Alan Mackenzie (Nuremberg, Germany).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]