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: Mon, 04 Dec 2023 17:59:46 -0500 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="9343"; 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 Tue Dec 05 00:01:27 2023 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 1rAHwL-0002FX-AZ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 05 Dec 2023 00:01:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rAHvv-0007b3-V0; Mon, 04 Dec 2023 18:00:59 -0500 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 1rAHvo-0007ag-3B for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 18:00:57 -0500 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 1rAHvn-0001bt-RF for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 18:00:51 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rAHvy-00006q-Io for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 18:01:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Dec 2023 23:01: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.1701730824350 (code B ref 67455); Mon, 04 Dec 2023 23:01:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 4 Dec 2023 23:00:24 +0000 Original-Received: from localhost ([127.0.0.1]:36064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rAHvM-00005a-9E for submit@debbugs.gnu.org; Mon, 04 Dec 2023 18:00:24 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41127) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rAHvK-00005J-PQ for 67455@debbugs.gnu.org; Mon, 04 Dec 2023 18:00:23 -0500 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8320D80663; Mon, 4 Dec 2023 18:00:06 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1701730805; bh=a2IWF1vz3uRLCX1lx9dwEzToD8TM/XB/WKJxo7CMdr0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=HuGl7iadcIRKoLOQwuoQVPjsAiVJcY6c+NhwWXbB64rrjS7uDvX45L+Q6J8gE98jd hWF9ke/c51b1YqKYO4SP9Z+C2R8U8MZLrQCfBOX1qtkfpUwR2gQ4ICl5dwWEU4reMp si5OgGZSExyKJC3XQOaZot/2GGonphmSgEDHKjPP8iw984STqYOl5R+2sC4iMFSkq1 Pg7QFrBv69fp2ElMyL5pmEGnBzwGJ9k+UemPaDNkzxVvDE82tfuuCSwfF3ubSnasB0 Aqh+SXkp+/Lsp/RMMHzvw+soa5yuKuvm7Ta+2lDGBvSZbuHO5g7maOwJ/m0p7W2v6C L8X3+cH/KU1Dg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6D1268054F; Mon, 4 Dec 2023 18:00:05 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 52848120388; Mon, 4 Dec 2023 18:00:05 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Mon, 4 Dec 2023 22:30: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:275542 Archived-At: > Maybe, though, it would be useful in some circumstances to record the > buffer the definition was loaded from if it's not a file. But it's > getting rather late here, so I haven't thought this through at all. I think if it comes from a buffer (and one that's not associated with a file, to boot), it's usually not byte-compiled, so I suspect you'll be better off confining that handling to the interpreted case. >> >> > the position of the defining symbol in the file, and the position of >> >> > the lambda (should we be in one) in the file. >> >> Why two positions? >> >> Why not use the same position info as used in `byte-compile-warn-x`? >> > I'm not sure, yet, but I suspect both positions will be useful. >> Can you give an example scenario? > Something about a lambda form, when we need to find the lambda itself, > but also its containing form. Sorry I can't be more definite, yet. I'm having a hard time imagining why you'd need two positions. Instead, I want to go to *the* position, which should be "the best we can come up with". And that's also what `byte-compile-warn-x` wants and it has access to the same information. IOW if you think you can do better for lambdas-with-pos, then please try and retro fit it into `byte-compile-warn-x`. >> Ah, got it. I like the way you can refer to args by name. >> So I guess all the (defining-symbol 1) could similarly be replaced with >> (defining-symbol THE-ARG-NAME). > Yes, I hadn't really thought of that. But (defining-symbol 1) matches > similar forms like (docstring 3) which are used somewhere. (defining-symbol N) is nice as well. > Ah, the debug spec; yet another difficult domain specific language. ;-( Yup. It's even worse, because at this stage I don't think anyone truly understands its semantics. [ I just wish we had a "similar" DSL that served /all/ those purposes, i.e. would let the macro writer express where the docstring is (if any), where the defining names are, how to indent each part, how to instrument each part, ... And of course, with a well-defined and well-understood semantics, a simple implementation (that works efficiently for all those uses), and a simple&concise syntax. Oh and while at it, it would also be used during macro-expansion to provide meaningful error messages when the macro is used incorrectly. Clearly, [Fortifying macros](https://dl.acm.org/doi/10.1145/1863543.1863577) can provide useful inspiration. ] Stefan