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 16:56:41 -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="32470"; 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 Mon Dec 04 22:58:09 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 1rAGx6-0008EM-OW for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Dec 2023 22:58:08 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rAGws-0004gg-F1; Mon, 04 Dec 2023 16:57:54 -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 1rAGwp-0004gM-5K for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 16:57:51 -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 1rAGwo-0003Q1-TR for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 16:57:50 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rAGwz-0006gG-KC for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 16:58: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: Mon, 04 Dec 2023 21:58: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.170172704425625 (code B ref 67455); Mon, 04 Dec 2023 21:58:01 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 4 Dec 2023 21:57:24 +0000 Original-Received: from localhost ([127.0.0.1]:35974 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rAGwO-0006fE-5n for submit@debbugs.gnu.org; Mon, 04 Dec 2023 16:57:24 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:1404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rAGwM-0006f2-58 for 67455@debbugs.gnu.org; Mon, 04 Dec 2023 16:57:22 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id AAF3D44447D; Mon, 4 Dec 2023 16:57:05 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1701727020; bh=G/fkIM6F5zW3O90JBC531aFzoZ/F1Uhe0vO4lpHl/GI=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=mefNrHWk2AArvMPh8rexl+LnVNjkiEKCLyFOs94TpBcohqI2IBqO4S6cctcY/QNxV ERnazDZ/yEJe2XrCDvhAcpATvb87sSMbjjjwagOWQfogaEoEzsubiytG7ma+wbsoSi tnDqM1wzQMXPAqjK4LS4KltMv+IW/STqg2brua6pMuWqvLWJs2tyqUtFJsSF2BqZN/ fTsIcmqKFwezS5ia9oWC6HiYAnQo0yTg8Ez/imH+CsDY+J5SShCzjLwm4h6fMhn1nA LfbNmjp2XBXzXP16nCSf9KCn6zBRN+ef2GQm1FUAPluBvkfNEupMSjIOuhsnm4inhr BWOZ8HjXPH2+A== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 4EBA9444449; Mon, 4 Dec 2023 16:57:00 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3B5E11203A1; Mon, 4 Dec 2023 16:57:00 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Mon, 4 Dec 2023 21:32:19 +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:275540 Archived-At: >> Why include the file name? Presumably we will rely on a `(FILE . POS)` >> to find that docstring so including FILE in there is rather redundant >> (and in addition to that, this file name can be wrong if it's absolute >> since files often get moved between compilation and use). > No, the (FILE . POS) is the .elc file, the one I'm putting into the new > info is the source file. Until now, Emacs has always lived with the `.elc` file names (e.g. in `load-history`) and managed to find the corresponding `.el` file (when you try to jump to the source via `M-.` or by clicking in `C-h f`). It comes with its share of problems, but we've learned to live with them. Is there any reason you think this new functionality should go through the extra trouble to record the `.el` name (and thus develop its own set of workarounds for the cases where the `.el` doesn't live where we think it should)? >> > 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? >> > or (defining-symbol (if (consp struct) (car struct) struct)) >> [ Haven't seen that yet. ] > Have a look at cl-defgeneric and cl-defmethod in cl-generic.el. 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). [ I also notice that this extension is somewhat incompatible with the use I proposed for `font-lock`. :-( ] [ As you noted, this info is also related to the `&define` debug spec. I wish we could unify that information. ] Stefan