From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) Date: Sat, 30 Mar 2024 22:22:52 -0400 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19005"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 67455@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 31 04:24:35 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 1rqks6-0004ik-S0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Mar 2024 04:24:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rqkrf-0001fy-2d; Sat, 30 Mar 2024 22:24:07 -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 1rqkrZ-0001fp-D7 for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 22:24:01 -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 1rqkrY-0006JY-TI for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 22:24:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rqkra-0005z1-Dx for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 22:24:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 31 Mar 2024 02:24: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.171185180322830 (code B ref 67455); Sun, 31 Mar 2024 02:24:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 31 Mar 2024 02:23:23 +0000 Original-Received: from localhost ([127.0.0.1]:46385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqkqw-0005wA-Ve for submit@debbugs.gnu.org; Sat, 30 Mar 2024 22:23:23 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:62519) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqkqq-0005vM-TC for 67455@debbugs.gnu.org; Sat, 30 Mar 2024 22:23:20 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5E11C44230A; Sat, 30 Mar 2024 22:23:08 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711851786; bh=9d/8XKl4jDoCKn4v+BxJDJhRSnK3C0ld9YotuqTn4aY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=cx7k2sHshcJbI2zPZkHcXCs6rEKe6uBgLB3AMQcUMpi9YwTsaN9R16VUhfsXvflxc 2zT+5+b6YrpaIFQPP1wl4+SKE7a2mqyepHY40b+hmthdY7zNmI7+A8lHlRehU+P8ab v1VtE/GwgUHp/YNqduW0LsxXfvVOysl/58Zw5KBgxuG0BOENNJjulRsTbc0/z9xD8T /GPccvR7LcTlOe3KUmXh1ld5EWvDL+GDD6wpAhrWhy2mtisrkFMOwMoRYpYm9ELnD1 XV/yEIvUF8iT26NKd4rD6YINb1C/bNBDaEFm2WQZbOWCtof/T7owGQOaqj6XNukeWf 1L2ImHsCbAedQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D4E8F4422CD; Sat, 30 Mar 2024 22:23:06 -0400 (EDT) Original-Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A73781206FE; Sat, 30 Mar 2024 22:23:06 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sat, 30 Mar 2024 09:53:37 +0000") 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:282404 Archived-At: >> 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 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. 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. So "currently" (i.e. referring to *time*) is very problematic because it's only loosely correlated to what you're interested in. >> 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`. > 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). 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". Stefan