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: Sun, 10 Mar 2024 13:19:03 -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="9418"; 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 10 18:19:48 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 1rjMpu-0002Ek-OI for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Mar 2024 18:19:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rjMpf-0001Bp-BL; Sun, 10 Mar 2024 13:19:31 -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 1rjMpc-0001BT-VM for bug-gnu-emacs@gnu.org; Sun, 10 Mar 2024 13:19: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 1rjMpc-0000Nn-NH for bug-gnu-emacs@gnu.org; Sun, 10 Mar 2024 13:19:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rjMqA-0007kI-1b for bug-gnu-emacs@gnu.org; Sun, 10 Mar 2024 13:20: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, 10 Mar 2024 17:20: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.171009118629747 (code B ref 67455); Sun, 10 Mar 2024 17:20:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 10 Mar 2024 17:19:46 +0000 Original-Received: from localhost ([127.0.0.1]:37794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjMpt-0007jj-VJ for submit@debbugs.gnu.org; Sun, 10 Mar 2024 13:19:46 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjMps-0007jW-45 for 67455@debbugs.gnu.org; Sun, 10 Mar 2024 13:19:44 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 39295805EE; Sun, 10 Mar 2024 13:19:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1710091144; bh=d+lgK36D+WN9f1IyJduzV+Qdd135l9IM023nhPOEqeI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=azvDZBZ+mbhHzxNOKdT3PkYchOZjKxfnR/iS4i95+HlANt0ppm9cdMlPoo51UbNFj 34tarXfVwQEiQEPRlIrQoJhEhHUYuoCxey+RrokV4LH0iEZ4d48PBa0RgFu/6xaUPb 2trbhMfZLdZ5tmTZADNk3/Dz9W89w4BzIeBYNl6WZMG7/qVG879fXsfaMutX1nvzX3 mVke1epaSAQWPC2VxpFuFfWPZHdfLXbdhYNnm2YK1BixbEedsgbVKMdYMU4eA/vNxc qjfpUGz7jMFa9owNyz+x0pq864uqpCNOVm5Z4apUB45Gn8++dCKopwDkTeFXrPI90C OKutqTyUxycbQ== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1979480240; Sun, 10 Mar 2024 13:19:04 -0400 (EDT) Original-Received: from alfajor (69-165-147-56.dsl.teksavvy.com [69.165.147.56]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E1980120454; Sun, 10 Mar 2024 13:19:03 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Sun, 10 Mar 2024 16:02:31 +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:281411 Archived-At: > 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. Cool! >> - 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. This isn't quite right: during compilation, some code is read with positions (the code that we will compile), but some code is read in the normal way (the code we load for the purpose of running). The distinction is important. >> - 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. Hmm... here what you call "run time" is really some later macro-expansion, right? The `lambda` symbol comes from the first macro-expansion (ME1), but the docstring comes from the second (ME2). IIUC the problem you face is that you want to get the function's position info from the `lambda` symbol, which here would be wrong (even if we try to preserve it long enough), is that it? [ Tho, in more complex cases it becomes debatable whether the function's position should point to the position corresponding to ME1 or to that of ME2. ] More generally: what goes wrong in the above example if you just treat that as a list of symbol (stripping them all of their position info). AFAICT when *that* macro is expanded (i.e. ME2) you'll presumably get code like (mapatoms #'(lambda (FOO/p) (DO/p SOME/p (THING/p)))) right? [ where "/p" means that the symbol has a sympos. ] Isn't that sufficient info to add a docstring with position? >> (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. No matter how many extra tests you add to reduce the frequency, you're fundamentally adding a bug :-( Stefan