unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: How does one find out what file a library has been loaded from?
Date: Wed, 20 Jul 2022 11:47:11 +0000	[thread overview]
Message-ID: <YtfrP84c5Q2hl2og@ACM> (raw)
In-Reply-To: <83fsiwncem.fsf@gnu.org>

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

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

-- 
Alan Mackenzie (Nuremberg, Germany).



  reply	other threads:[~2022-07-20 11:47 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-19 10:52 How does one find out what file a library has been loaded from? Alan Mackenzie
2022-07-19 12:39 ` Eli Zaretskii
2022-07-19 15:01   ` Alan Mackenzie
2022-07-19 15:32     ` Andrea Corallo
2022-07-24 16:07       ` Eli Zaretskii
2022-07-24 17:46         ` Andrea Corallo
2022-07-31 12:52           ` Eli Zaretskii
2022-08-01  9:23             ` Andrea Corallo
2022-08-02  8:43               ` Andrea Corallo
2022-08-02 12:12                 ` Eli Zaretskii
2022-08-02 14:13                   ` Andrea Corallo
2022-08-03 14:19                     ` Eli Zaretskii
2022-08-01 19:31             ` Alan Mackenzie
2022-08-03 14:16               ` Eli Zaretskii
2022-07-19 15:50     ` Eli Zaretskii
2022-07-19 17:07       ` Alan Mackenzie
2022-07-19 19:13         ` Eli Zaretskii
2022-07-20 11:47           ` Alan Mackenzie [this message]
2022-07-20 15:31             ` Stefan Monnier
2022-07-20 20:34             ` Alan Mackenzie
2022-07-21  6:13               ` Eli Zaretskii
2022-07-21 17:37                 ` Alan Mackenzie
2022-07-21 17:52                   ` Stefan Monnier
2022-07-21 18:24                     ` Alan Mackenzie
2022-07-21 18:37                       ` Stefan Monnier
2022-07-21 21:03                         ` Alan Mackenzie
2022-07-21 23:15                           ` Stefan Monnier
2022-07-21 17:53                   ` Eli Zaretskii
2022-07-21 20:39                     ` Alan Mackenzie
2022-07-23 10:11                       ` Eli Zaretskii
2022-07-24 11:27                         ` Alan Mackenzie
2022-07-24 12:16                           ` Eli Zaretskii
2022-07-24 15:37                             ` Eli Zaretskii
2022-07-24 15:42                               ` Eli Zaretskii
2022-07-24 15:32                           ` Stefan Monnier
2022-07-24 15:49                             ` T.V Raman
2022-07-24 16:11                               ` Stefan Monnier
2022-07-24 18:21                                 ` T.V Raman
2022-07-24 18:50                                   ` Stefan Monnier
2022-07-24 16:19                               ` Eli Zaretskii
2022-07-19 16:27     ` Stefan Monnier
2022-07-20 18:36       ` Andrea Corallo
2022-07-21  7:20         ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YtfrP84c5Q2hl2og@ACM \
    --to=acm@muc.de \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).