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 10:57:50 +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="23357"; 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 12:59: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 1rtQF7-0005wa-QN for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Apr 2024 12:59:21 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rtQEk-0002l5-1M; Sun, 07 Apr 2024 06:58: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 1rtQEj-0002ku-40 for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 06:58:57 -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 1rtQEi-0000tJ-Rh for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 06:58:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rtQEo-0002qF-Iu for bug-gnu-emacs@gnu.org; Sun, 07 Apr 2024 06:59: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 10:59: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.171248749110702 (code B ref 67455); Sun, 07 Apr 2024 10:59:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 7 Apr 2024 10:58:11 +0000 Original-Received: from localhost ([127.0.0.1]:41697 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtQDy-0002mU-M6 for submit@debbugs.gnu.org; Sun, 07 Apr 2024 06:58:11 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:42604) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rtQDv-0002l2-Am for 67455@debbugs.gnu.org; Sun, 07 Apr 2024 06:58:09 -0400 Original-Received: (qmail 52805 invoked by uid 3782); 7 Apr 2024 12:57:54 +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 12:57:54 +0200 Original-Received: (qmail 9814 invoked by uid 1000); 7 Apr 2024 10:57:51 -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:282861 Archived-At: Hello, Stefan. Sorry about the delay - I lost my email server after an obsolete SSL library got deleted from my system, and one or two other things, too. On Sat, Mar 30, 2024 at 22:54:18 -0400, Stefan Monnier wrote: > > 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. Pretending the problem doesn't exist won't solve it. In the ;POS... structures for a lambda, there are two pointers - one to the definition of the lambda, the other to the point of use. > 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, .... Mostly there is the symbol `function' in that position. Here we've got `cl-function' which expands to function. Surely with (function (lambda ....)) we know we're dealing with 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. I don't think this is right. The code will pass through macroexp--expand-all, which is where the SWP wii be stripped. > IOW, I don't think it's a good reason to rule out > (strip-all-symbol-positions > (macroexp--expand-all > (read-positioning-symbols))) As I've said, we'd need code to preserve the SWPs on "complicated" lambdas. I haven't even begun to think about how this could work. > 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`). It is a bad idea to conflate these two radically different uses of SWPs. That can only lead to confusion and bugs. > 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? No, the intention is that the source positions are independent of whether the code is 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)) > > expands 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? In macroexp--expand-all in the "guard arm" near the end. > > 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. See above. > >> 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? The mass of detail that needs dealing with that Emacs has collected over the decades. As a counter question, why do you think the exercise ought to be simple (assuming you do think this)? > > 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). "Comparable" isn't good enough - we need the position info on "complicated" lambdas to endure, somehow. There are no discrepancies between compiled and interpreted forms because they both use the same mechanism in macro expansion. > My main worry with it would be performance. Yhat, too. > Stefan -- Alan Mackenzie (Nuremberg, Germany).