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:54:18 -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="39234"; 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:55:22 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 1rqlLu-0009zw-8u for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 31 Mar 2024 04:55:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rqlLb-00051u-V7; Sat, 30 Mar 2024 22:55:03 -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 1rqlLa-00051j-5k for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 22:55:02 -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 1rqlLZ-0003Oo-Tm for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 22:55:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rqlLb-0007Yg-Pv for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 22:55:03 -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:55:03 +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.171185367528972 (code B ref 67455); Sun, 31 Mar 2024 02:55:03 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 31 Mar 2024 02:54:35 +0000 Original-Received: from localhost ([127.0.0.1]:46391 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqlL8-0007X4-1Q for submit@debbugs.gnu.org; Sat, 30 Mar 2024 22:54:35 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8481) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqlL2-0007WM-Jp for 67455@debbugs.gnu.org; Sat, 30 Mar 2024 22:54:32 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 5B59780D32; Sat, 30 Mar 2024 22:54:20 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1711853659; bh=Kmy0kHc7a0ROClM4leLEGhaH10nEt9IbyIeyerymD3M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=gMYmmuMAskngBgFueaIk8sakczYYAeoYxeBmzvWOyB23W+g7/zDrVbPPtaB2GfJOR AEZIuWpI8VZAzA8hHe7buh21Yppuvn8sPa+XHh/9hTDdGr/lBeH1PMc9UMqWcZeXef BTxbCHSNJyG9BZdMx6HZmRFL0OCSyEVTJy8ARlQaX6GZJtRwGJxApg6V1TmCBWrmYJ +T5Oc2AZpdbJELqISSnoiYlWix1Fuy6P6DWl9aguPIiLO+DhUhKglyTb8Wb700IVse W4sCRCV/4Oc9EIGxRIIdnjw35DrOL3lZEG1XlQvOdLsH1PKYLLAbBuLXm7XqupeD+1 YIlu1eXvK4ekA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 36E808036C; Sat, 30 Mar 2024 22:54:19 -0400 (EDT) Original-Received: from pastel (unknown [45.72.201.215]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 0D608120426; Sat, 30 Mar 2024 22:54:19 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sat, 30 Mar 2024 11:03:38 +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:282405 Archived-At: > Some symbols must not be stripped. For example, in cl-generic.el L403 > we have: > > (fun `(cl-function (lambda ,plain-args ,@body))) > > .. There the position on the lambda must be preserved until ME2 time > when it becomes clear what the shape of the lambda is. In particular, > whether there is already a doc string in ,@body to amend, or we need to > insert a new one. I could see some reasons you *may* want to keep some info here, but it's definitely not a "must" because the source position of those functions should generally not point to `cl-generic.el:403` but to where `cl-defmethod` was used. Also, if you do want to preserve some info there (presumably with the intent to combine it with the more important info that will be available at ME2) it will need cooperation from `cl-generic.el` because, as far as the semantic of Emacs Lisp is concerned, the above constructs a list with a `lambda` symbol inside of it, with no guarantee that it will be used as a function, and even if ever used as a function there's no guarantee that this list will pass through the few places where we strip SWPs, so keeping SWPs in there without some explicit request from `cl-generic.el` would be a bug. IOW, I don't think it's a good reason to rule out (strip-all-symbol-positions (macroexp--expand-all (read-positioning-symbols))) BTW, AFAIK the above is conceptually what the byte-compiler does (except it performs a few more transformations between `macroexp--expand-all` and `strip-all-symbol-positions`). Is it the case that `cl-defmethod` generates a function whose source position (partly) points to `generic.el:403` if `cl-generic.el` was interpreted but not if it compiled? >> >> >> Also, IIUC you don't have a separate phase to strip the SWPs when >> >> >> loading from source, but instead you strip them as you "consume" their >> >> >> info during macroexpansion. If so, how/when/where do you strip the >> >> >> false positives that may occur inside quoted data or in code like: > >> >> >> (defmacro foo (lambda bar) ...) > > (defmacro foo (lambda bar) > `(cons ,lambda ,bar)) > > exoands to > > (macro closure (t) (lambda bar) ";POS^^^A^A^A [foo *scratch* 158 nil] > " (list 'cons lambda bar)) IIUC your reader will make the `lambda` formal argument into an SWP. Where is that SWP stripped? > so it is clear this case is getting handled OK. I'm afraid I can't > point out the exact place in the code at the moment where this is > getting done. I think it would be good to know, so as to be able to decide whether it'll indeed always work right, or we just got lucky this time. >> I don't actually know whether it will be better. It just seems it could >> lead to simpler code, with no change at all to the reader, for example. > The exercise is intrinsically complicated. Could you explain what you think makes it intrinsically complex? > What you're suggesting is that the code to decide which SWPs to strip > is going to be simpler than the enhancements to the reader. As seen above, I suggest to leave the reader unchanged and to strip all SWPs. I'm pretty sure it would give comparable info to what you have and it would be simpler (also, it would make it much less likely to have discrepancies between the compiled case and the interpreted case). My main worry with it would be performance. Stefan