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: Mon, 4 Dec 2023 22:30: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="11693"; 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 Mon Dec 04 23:31:31 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 1rAHTP-0002tx-9M for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Dec 2023 23:31:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rAHSv-0002yD-QG; Mon, 04 Dec 2023 17:31:02 -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 1rAHSp-0002xP-Ke for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 17:30: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 1rAHSl-00089c-Rw for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 17:30:54 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rAHSw-0007cr-A5 for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 17:31:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Dec 2023 22:31: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.170172905129290 (code B ref 67455); Mon, 04 Dec 2023 22:31:02 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 4 Dec 2023 22:30:51 +0000 Original-Received: from localhost ([127.0.0.1]:36013 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rAHSl-0007cM-8o for submit@debbugs.gnu.org; Mon, 04 Dec 2023 17:30:51 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:24296) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rAHSi-0007c9-Re for 67455@debbugs.gnu.org; Mon, 04 Dec 2023 17:30:49 -0500 Original-Received: (qmail 89250 invoked by uid 3782); 4 Dec 2023 23:30:32 +0100 Original-Received: from acm.muc.de (pd953aae0.dip0.t-ipconnect.de [217.83.170.224]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 04 Dec 2023 23:30:31 +0100 Original-Received: (qmail 13735 invoked by uid 1000); 4 Dec 2023 22:30: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:275541 Archived-At: Hello, Stefan. On Mon, Dec 04, 2023 at 16:56:41 -0500, Stefan Monnier wrote: > >> 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. Yes. I've come to the same conclusion in the last hour or so that, no doubt, early Emacs hackers reached forty years ago. We can find the ..elc full filename from load-history (via symbol-file), but there's no more useful way of finding the corresponding source than removing the 'c' from the end of foo.elc. And if it's not there, it's nowhere. > 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)? Not any more, having thought it through. 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. > >> > 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. When I start hacking out the code to use all this information, it will become clearer what we actually need. It's very easy to change at this stage. > >> > 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). Yes, I hadn't really thought of that. But (defining-symbol 1) matches similar forms like (docstring 3) which are used somewhere. > [ 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. ] Ah, the debug spec; yet another difficult domain specific language. ;-( > Stefan -- Alan Mackenzie (Nuremberg, Germany).