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: Fri, 15 Dec 2023 18:12:42 -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="32084"; 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 Sat Dec 16 00:13:28 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 1rEHN1-00089e-5x for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Dec 2023 00:13:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rEHMf-0007Lw-SW; Fri, 15 Dec 2023 18:13:05 -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 1rEHMc-0007Ll-42 for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 18:13:02 -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 1rEHMb-0003UZ-Ra for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 18:13:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rEHMb-0002CO-P5 for bug-gnu-emacs@gnu.org; Fri, 15 Dec 2023 18:13:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 15 Dec 2023 23:13: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.17026819738439 (code B ref 67455); Fri, 15 Dec 2023 23:13:01 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 15 Dec 2023 23:12:53 +0000 Original-Received: from localhost ([127.0.0.1]:53736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEHMT-0002C1-DB for submit@debbugs.gnu.org; Fri, 15 Dec 2023 18:12:53 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rEHMR-0002Bm-9C for 67455@debbugs.gnu.org; Fri, 15 Dec 2023 18:12:51 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4B5B3444BC9; Fri, 15 Dec 2023 18:12:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1702681963; bh=ILel/5mtuiJEj50Ui1Xv8cfaOHrMxgrbJXPwgFjEWOo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Gz+QK41d7WAvEZwi3NGFEvKBSte5QPx3Mv3Tgb4nzTehPCF8YcZjGBhFldhHIDQcY yHbQ9r3jWgLGaiboJkoWycipezOGYK5N/1RCRkQxIzTLJ0sjr6jWXxgeuf/U5HQ0dm ePo5qT1Kee/CBblQ69W0ucXaPxWbI0hwDh4G2Mla/iOKyG+IAqhtO0HEhUvBJHulGN ZH9IQQne2zDdUxo80Lu1qKTkOgY67l5fSTK8lPELaj2Kh2dO5ATRfSw42A8D38aeq7 EzqdLkYbWA+SDAUxWC43iiBniXIMb00dcKZJPEadZ44mneg2M+BUqPwQL5baIvUE9l ocEuQ7Dav0nlw== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id CEC7D444BC2; Fri, 15 Dec 2023 18:12:43 -0500 (EST) Original-Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A8A191201CA; Fri, 15 Dec 2023 18:12:43 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Fri, 15 Dec 2023 18:23:41 +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:276293 Archived-At: > The problem that has thrown me is the use of the doc string in oclosures > for other purposes. For example, in position 2 of a lambda form, > appears something like > > (:documentation 'oclosure-accessor) Hmm... > .. My current code is expecting, on encountering (:documentation ...), > for the cadr to be a string, `:documentation` is supposed to be followed by an expression (whose evaluation should usually return a string, although indeed we abuse it in the case of OClosures to return a symbol instead). Regardless of OClosures, the `cadr` of a `:documentation` will very rarely be a mere string since you don't need `:documentation` when the docstring can be written as a literal. > onto which it can add a concat form which > will prefix the position information. For the non-OClosure case you should be able to use the equivalent of: (:documentation (concat )) is that what you mean? > A solution to this problem would be to move the above symbol to element > 2 of the list, something like > > (:documentation nil 'oclosure-accessor) Here you're talking about the source code, right? I think the question is rather what representation to use in the values: OClosures store their type name (symbol) in the slot that normally holds the docstring, so I think the best short term answer is to say that OClosures aren't supported by your new feature. OClosures are a mix of functions and structs, so while it would be nice to make them enjoy your new feature, I think it's perfectly OK to say that in this respect they're more like structs than like functions. Also they come with more introspection features than normal functions, so it's usually easier to figure out where they come from (you can find their type, and then look for the `oclosure-lambda`s which built OClosures of this type. For most OClosure types, there's only one such lambda anyway). > , so that my new code could place its information in the now vacant > position 1, giving something like > > (:documentation ";POS\36\0\0\0 [ .... ]\n" 'oclosure-accessor) > > .. What do you think of this idea, and have you any better ideas for a > solution to the problem? If it works it might be a good option. I don't know how this turns into when we build the corresponding bytecode object, so it's hard to judge. Stefan