From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.bugs Subject: bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) Date: Sun, 7 Apr 2024 11:35:19 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3817"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Eli Zaretskii , 67455@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Apr 07 13:36:23 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1rtQow-0000q3-Us for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Apr 2024 13:36:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rtQoX-0000yH-SU; Sun, 07 Apr 2024 07:35:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rtQoW-0000xk-2Y for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 07:35:56 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rtQoV-0007bi-Qd for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 07:35:55 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rtQoc-0000MS-9b for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 07:36:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Apr 2024 11:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67455 X-GNU-PR-Package: emacs Original-Received: via spool by 67455-submit@debbugs.gnu.org id=B67455.17124897371230 (code B ref 67455); Sun, 07 Apr 2024 11:36:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 7 Apr 2024 11:35:37 +0000 Original-Received: from localhost ([127.0.0.1]:41709 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtQoD-0000Jl-2m for submit@debbugs.gnu.org; Sun, 07 Apr 2024 07:35:37 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:59965) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtQoB-0000JY-OR for 67455@debbugs.gnu.org; Sun, 07 Apr 2024 07:35:36 -0400 Original-Received: (qmail 96078 invoked by uid 3782); 7 Apr 2024 13:35:22 +0200 Original-Received: from muc.de (pd953a949.dip0.t-ipconnect.de [217.83.169.73]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 07 Apr 2024 13:35:22 +0200 Original-Received: (qmail 9924 invoked by uid 1000); 7 Apr 2024 11:35:19 -0000 Content-Disposition: inline In-Reply-To: X-Submission-Agent: TMDA/1.3.x (Ph3nix) X-Primary-Address: acm@muc.de X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:282863 Archived-At: Hello, Stefan. On Sat, Mar 30, 2024 at 22:22:52 -0400, Stefan Monnier wrote: > >> We're still miscommunicating. You're talking about how your code is > >> implemented, apparently, whereas I'm asking about what is the > >> intended behavior. > > I am still mystified by your failure to understand "currently being > > defined", a phrase that to me could hardly be clearer. > AFAIK, the definition itself happens inside `Fdefalias`. It's a very > short amount of time during which none of your code is executed, so that > can't be it. The definition starts when the reader reads (defun foo ...). It ends when that Fdefalias has been evaluated. Between those two events, defining-symbol is bound to foo. > The rest is the actual construction of the value/function object which > will make up the definition. This construction is done piecemeal in > various phases at potentially various different times, not all of them > necessarily on the same machine. Really? :-) > Some of the code executed during the course of the construction of this > object have nothing at all to do with that object, they just happen to > be used by some code which participates in the construction of that > object. That's a bit too abstract. I can't see the potential problems that you see, possibly because I've already solved them. > So "currently" (i.e. referring to *time*) is very problematic because > it's only loosely correlated to what you're interested in. Again, I don't see these problems. > >> It's like I'm asking what the C spec says and you're answering me by > >> telling me how GCC works. > > OK, let's try again. defining-symbol records the symbol currently being > > defined. It's used to set the defining symbol and buffer offset fields > > in the position structure in that symbol's doc string, and also in the > > doc strings of contained lambda forms. > I can try it again also if you want: to do it right, I think you want to > store that information in `macroexpand-all-environment`. That variable doesn't exist, yet. > > Is my previous paragraph sufficiently clear? If so, can you envisage a > > scenario where a symbol being defined would fail to get the two fields > > correctly set in its doc string or a lambda form's doc string? > Yes, for example I can imagine a lazy macroexpansion done to run some > code during the eager macroexpansion could mistakenly think that it is > part of the eagerly macroexpanded function (whereas it's only part of > the code used during the construction of that function). The critical thing here is the variable defining-symbol. I think you're suggesting that its value could accidentally find its way into other symbols' position structures. When are those other symbols getting defined? Surely if a secondary defun, defmacro, defvar, ... happens during the main defun, its defining symbol is that of the main defun? > I'm sure there are other cases, by thinking of it makes my head hurt. > Which is why I recommend you put that info into > `macroexpand-all-environment` which is designed specifically for such > purpose of "currently within the scope of something". Well, m-a-e is defined too late. Even if it weren't, how would it solve any of these problems you see? It's just swapping one dynamically bound variable for another. > Stefan -- Alan Mackenzie (Nuremberg, Germany).