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, 10 Mar 2024 16:02:31 +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="3713"; 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 Mar 10 17:03:43 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 1rjLeI-0000r7-HC for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Mar 2024 17:03:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rjLe6-0000Lx-Bd; Sun, 10 Mar 2024 12:03:30 -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 1rjLe4-0000Ji-Qd for bug-gnu-emacs@gnu.org; Sun, 10 Mar 2024 12:03:28 -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 1rjLe4-0004qi-Gz for bug-gnu-emacs@gnu.org; Sun, 10 Mar 2024 12:03:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rjLeb-0005Ub-LI for bug-gnu-emacs@gnu.org; Sun, 10 Mar 2024 12: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: Sun, 10 Mar 2024 16: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.171008659721049 (code B ref 67455); Sun, 10 Mar 2024 16:04:01 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 10 Mar 2024 16:03:17 +0000 Original-Received: from localhost ([127.0.0.1]:37750 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjLdr-0005TN-7c for submit@debbugs.gnu.org; Sun, 10 Mar 2024 12:03:17 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:61997) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjLdn-0005T1-TL for 67455@debbugs.gnu.org; Sun, 10 Mar 2024 12:03:13 -0400 Original-Received: (qmail 59807 invoked by uid 3782); 10 Mar 2024 17:02:32 +0100 Original-Received: from acm.muc.de (pd953a236.dip0.t-ipconnect.de [217.83.162.54]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 10 Mar 2024 17:02:32 +0100 Original-Received: (qmail 31889 invoked by uid 1000); 10 Mar 2024 16:02:31 -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:281404 Archived-At: Hello, Stefan. Thanks for looking at my patch! I've got a version almost ready which actually does something, namely prefixes "anonymous" lines of a backtrace with the name of the defining symbol, like {foo} . It'll soon be time to start seriously thinking about what information ought to go there for the live version. Unfortunately, I've still got two blocking issues to resolve - one is a change in functionality to Fbare_symbol, which I've reported as a bug; the other is some new code merged in from master, a with-eval-after-load clause in pcase.el which causes havoc in my build. Still, progress is being made. On Sat, Mar 09, 2024 at 16:36:57 -0500, Stefan Monnier wrote: > > I've just pushed a large commit to feature/positioned-lambdas, a work > > in progress commit for bug#67455, putting source position information at > > the start of doc strings. master was merged into it just before the > > commit. > I barely started to look at the code, but regarding the following hunk: > diff --git a/lisp/emacs-lisp/backquote.el b/lisp/emacs-lisp/backquote.el > index 6917128d70a..0d4681bc979 100644 > --- a/lisp/emacs-lisp/backquote.el > +++ b/lisp/emacs-lisp/backquote.el > @@ -172,6 +172,30 @@ backquote-process > (backquote-delay-process s (1- level)))) > ((eq (car s) backquote-backquote-symbol) > (backquote-delay-process s (1+ level))) > + ;; Process a (lambda ...) form specially, since otherwise the > + ;; lambda symbol would get separated from its introductory (, > + ;; preventing this processing from being done elsewhere in macro > + ;; expansion. > + ((and (eq (car s) 'lambda) > + (symbol-with-pos-p (car s)) > + (listp (car-safe (cdr s)))) > + (let ((kdr (backquote-process (cdr s) level)) > + (lambda-pos (symbol-with-pos-pos (car s))) > + ) > + (if (null byte-compile-in-progress) > + (setcar s 'lambda)) ; Strip the position. > + (cond > + ((= (car kdr) 0) > + (cons (car kdr) > + (list 'quote > + (byte-run-posify-lambda-form > + (cons (car s) (car (cdr (cdr kdr)))) ; Two cdr's to strip 'quote. > + lambda-pos)))) > + (t > + (cons 1 > + (list 'byte-run-posify-lambda-form > + (list 'cons (list 'quote (car s)) (cdr kdr)) > + lambda-pos)))))) > (t > (let ((rest s) > item firstlist list lists expression) > - Testing `byte-compile-in-progress` can't be right. Do you to test > whether the result of this backquote will be byte-compiled or do you > really mean to test whether this backquote happens to be executed > during compilation (which could be because the compiler ends up > loading code while executing `eval-when-compile` or `require`)? Quite simply, during compilation, all symbols (except nil) get read with position, so to strip their positions here would be wrong. Outside of compilation (an evaluation of a defun, for example), only defined symbols get positioned, and these symbols with position would interfere with Emacs's working. So they get stripped of their positions as soon as possible after the info has been transferred to the doc string. For example, SWPs cannot be dumped by the portable dumper. > - My gut tells me that changing backquote can't be right. I tend to agree. I put the code into backquote-process when having problems with things like: (mapatoms #'(lambda (,(car spec)) ,@body) in cl-macs.el, where it's impossible to know where the doc string (if any) is until after the expansion of the backquotes, or even at run time (as here). In the latter case, rather than "posifying" the doc string at macro expansion time, we have to generate code to do it at run time. > (lambda (f) ..) *can* appear within a backquote without it being an > actual lambda expression. > What alternatives have you considered? Not a lot of them, as yet. Maybe testing for (function (lambda ...)) would be safer. But I think I should try and find some other way of solving these problems than altering backquote.el, which should be easier now that the code is basically working. > Stefan -- Alan Mackenzie (Nuremberg, Germany).