From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: How does one find out what file a library has been loaded from? Date: Sat, 23 Jul 2022 13:11:54 +0300 Message-ID: <83k084i1ed.fsf@gnu.org> References: <83bktlnuog.fsf@gnu.org> <83sfmxm79z.fsf@gnu.org> <83fsiwncem.fsf@gnu.org> <83mtd3ngcw.fsf@gnu.org> <838rommjxj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15805"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Jul 23 12:13:39 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oFC8d-0003rD-Md for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jul 2022 12:13:35 +0200 Original-Received: from localhost ([::1]:57648 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oFC8c-0003O4-CM for ged-emacs-devel@m.gmane-mx.org; Sat, 23 Jul 2022 06:13:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56800) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFC77-0002eQ-Qg for emacs-devel@gnu.org; Sat, 23 Jul 2022 06:12:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:36576) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFC75-0003K5-Cy; Sat, 23 Jul 2022 06:12:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=cd+5jsTenCo0I/U5VS26U2VU1iMpYHhlt+Q+MaxLtIQ=; b=Rbq+XhyZEe2/ /uMxhnIH5AP4LRvJzgSv8UzNr+SrRltLLcIFF8YXHnF9szgdVaZtuv0W06fscgG+TsvYMk/QbSrr5 oaaEK9a8mPgFclAO9uGLiGf7NPftvnB+t7EA53bS8coUUzIqG28dn1SYj7dj38543WFrbcxxPlbHQ FfXXlBS7iqVQlp9XnQ2nTXajETlt3jv34+IkP8oJSai8vOVX6riYDAh/XbpeEoYjnU/4Xc8mr4tnf 6P421gmx1E8Dfy/zcat92c0IlxaCxaCeAQbfmReQpRFK3k826SS1nE53pcrklFC+EuZt+7sjVJdYA yHXitxL1JUvj5SRo5859Aw==; Original-Received: from [87.69.77.57] (port=4984 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oFC74-0007MD-2B; Sat, 23 Jul 2022 06:11:59 -0400 In-Reply-To: (message from Alan Mackenzie on Thu, 21 Jul 2022 20:39:48 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:292516 Archived-At: > Date: Thu, 21 Jul 2022 20:39:48 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > > > > +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. But that is not true. The original text says something definitive and useful. Adding information to it should NOT lose any of the information that was there to begin with, because that information still correct and not obsolete. > 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. It is never a good thing to say "as much as you can say" if it leaves the reader less wise. > > 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. Then TRT is to say what happens normally, and then add the description of what happens in exceptional cases, including the description of when the exceptions happen. > 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 What does symbol-file has to do with any such "relationship"? All you want to _add_ is that in an Emacs with native-compilation, loading a .elc file can eventually load the corresponding .eln file instead. So why not just say that? > > 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? Because it uses functions not described in the manual. > Would it be better to write a new function incorporating the > procedure, and document that? In principle, yes. But we need to discuss first what would that function be. See below. > > > 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. You are splitting hair, but let me rephrase: if you cannot figure it out in some reasonable amount of time, feel free to ask. > > > 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? I just told you about it. I told you about it not as an accusation, but as a way to help you find the best way of solving your problem. > It generates file names which might not name existing files. It > doesn't seem ideal for the purpose. Then I think you should describe the purpose better and in more detail. What exactly are you trying to accomplish and why? What is the data from which you start and what is the data you want to obtain as result? In particular, is the starting point a function or a file name? or something else entirely?