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: Sat, 30 Mar 2024 11:03:38 +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="832"; 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 Sat Mar 30 12:04:27 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 1rqWVe-000AZ5-Q5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Mar 2024 12:04:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rqWVF-0004Bj-Ik; Sat, 30 Mar 2024 07:04:01 -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 1rqWVE-0004BV-39 for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 07:04:00 -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 1rqWVD-0006jC-Rb for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 07:03:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rqWVF-0006CH-M3 for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 07:04:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 30 Mar 2024 11:04:01 +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.171179662923801 (code B ref 67455); Sat, 30 Mar 2024 11:04:01 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 30 Mar 2024 11:03:49 +0000 Original-Received: from localhost ([127.0.0.1]:44062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqWV2-0006Bp-Vl for submit@debbugs.gnu.org; Sat, 30 Mar 2024 07:03:49 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:36502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqWV1-0006Bc-3P for 67455@debbugs.gnu.org; Sat, 30 Mar 2024 07:03:47 -0400 Original-Received: (qmail 61056 invoked by uid 3782); 30 Mar 2024 12:03:39 +0100 Original-Received: from acm.muc.de (p4fe15358.dip0.t-ipconnect.de [79.225.83.88]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 30 Mar 2024 12:03:38 +0100 Original-Received: (qmail 6296 invoked by uid 1000); 30 Mar 2024 11:03:38 -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:282346 Archived-At: Hello, Stefan. On Thu, Mar 28, 2024 at 12:25:11 -0400, Stefan Monnier wrote: [ .... ] > >> >> Do you have rough numbers comparing the cost of `read`, > >> >> `read-positioning-symbols`, and `read-positioning-DEFINED-symbols`? > >> > No, but they will be very close to eachother (and very cheap) > >> Then I think we should use `read-positioning-symbols`, which > >> requires fewer code changes. > > It won't. Required would be Lisp code to determine whether a particular > > SWP needs to be stripped or not. This is not going to be simple. It is > > likely to be about as complicated as the existing enhancements to read0. > They'd all need to be stripped, AFAICT, so we'd do: > (strip-all-symbol-positions > (macroexp--expand-all > (read-positioning-symbols))) > What would be hard about it? 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. > >> >> 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)) .. > >> >> (defmacro foo (defun bar) ...) > >> >> (let* ((lambda foo) > >> >> (defun bar)) > >> >> ...) Similarly, we get (defun baz () (let ((lambda 'foo) (defun 'bar)) (cons lambda defun))) (symbol-function 'baz) (closure (t) nil ";POS^^^A^A^A [baz *scratch* 323 nil] " (let ((lambda 'foo) (defun 'bar)) (cons lambda defun))) , 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. > >> > There's a pcase arm right at the end of macroexp--expand-all which strips > >> > SWPs of their positions. Recursing through macroexp--all-forms will > >> > eventually hit this pcase arm for these lambdas. > Actually, now that I look at the code I only see: > ((guard (and (not byte-compile-in-progress) > (symbol-with-pos-p form))) > (bare-symbol form)) > is that the "arm" you're talking about? Yes. > AFAICT this will handle only those symbols which appear as Lisp > expressions (IOW symbols which are variable references), so it will > strip the `bar` in the second example but not the `bar` in my first > exmple, nor the two `lambda`s, nor those in > '(lambda (defun bar)) See above. [ .... ] > > Why do you think this design change will be better than the existing > > design? > 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. read0 is largely self contained, meaning any compexity introduced there won't spill over into other functions. 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. > I'm here asking what lead you to the current design, under the > assumption that the complexity you introduced was the result of > other experiments. The complexity is essential to the task being done. I'm convinced it cannot be avoided, though it could be moved around the code base, to some extent. I don't have a record of the precise reasons for the design. To a large extent it was a sequence of solutions to the often awkward problems the code presented. > Am I to understand that the current code is basically your first attempt > at adding such functionality? By no means. This is the second implementation, the first having been rejected by Eli and you last autumn. I'm very much looking forward to not needing a third implementation. > Stefan -- Alan Mackenzie (Nuremberg, Germany).