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#66750: Unhelpful text in C-h v for variables with a lambda form as value Date: Sun, 29 Oct 2023 11:25:14 +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="33017"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66750@debbugs.gnu.org, Andrea Corallo , Stefan Kangas , acm@muc.de To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Oct 29 12:25:52 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 1qx3vT-0008Rq-Mg for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 29 Oct 2023 12:25:51 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qx3vE-0004C7-Kn; Sun, 29 Oct 2023 07:25:36 -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 1qx3v8-0004BI-FZ for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 07:25:31 -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 1qx3v8-0004wj-5O for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 07:25:30 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qx3ve-00051Q-9s for bug-gnu-emacs@gnu.org; Sun, 29 Oct 2023 07:26:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 29 Oct 2023 11:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66750 X-GNU-PR-Package: emacs Original-Received: via spool by 66750-submit@debbugs.gnu.org id=B66750.169857876019297 (code B ref 66750); Sun, 29 Oct 2023 11:26:02 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 29 Oct 2023 11:26:00 +0000 Original-Received: from localhost ([127.0.0.1]:40550 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qx3vb-00051A-VC for submit@debbugs.gnu.org; Sun, 29 Oct 2023 07:26:00 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:32619) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qx3vZ-00050u-D4 for 66750@debbugs.gnu.org; Sun, 29 Oct 2023 07:25:58 -0400 Original-Received: (qmail 57970 invoked by uid 3782); 29 Oct 2023 12:25:18 +0100 Original-Received: from acm.muc.de (p4fe15a23.dip0.t-ipconnect.de [79.225.90.35]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 29 Oct 2023 12:25:18 +0100 Original-Received: (qmail 4794 invoked by uid 1000); 29 Oct 2023 11:25:14 -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:273490 Archived-At: Hello, Stefan. On Sun, Oct 29, 2023 at 00:14:24 -0400, Stefan Monnier wrote: > >> > There are lots of detailed changes in eval.c and bytecomp.el (and > >> > friends). Also the macro `lambda' in subr.el has been amended to insert > >> > the current global defining-symbol if there isn't already a non-nil > >> > symbol in that position. > >> So the source code can manually provide this extra symbol in `lambda`? > >> Where have you found that useful? > > The first few functions in debug-early.el and byte-run.el, for a start. > > There, there is not yet a defmacro macro. Also in > > comp-trampoline-compile, where there doesn't seem to be any other way to > > get the name of the primitive into the defining symbol. I think there'll > > be quite a few other places, too. > Hmm... it seems like keeping the LINE+COL info rather than > a surrounding definition would be better in this regard since it wouldn't > require any changes at all to the actual lambdas, regardless where > they are. I don't agree with this. Whether we add FILE+LINE+COL info is to a large degree a separate question from that of adding defining symbol info. If you don't add information to the actual lambda, then that information won't be available when that lambda turns up in a backtrace or as a value in C-h v. Surely you'd have to keep FILE+LINE+COL in the lambda itself, somehow. That also assumes that the source file will be available and unchanged when it's needed. It will also stress the user somewhat, since it will force her to look up a file location to get any idea of what is failing. A defining symbol is much more immediately useful, even if it may not be 100% dependable because of the issues you raise below. > >> Hmm... as a user, rather than the enclosing definition I think I'd > >> expect to get some kind of source information like FILE+LINE+COL. > > Possibly: either is a good deal better than what we have at the moment. > The notion of "surrounding definition" is less precise (there can be > several lambdas inside a given definition, there can be lambdas outside > of any definition, ...). Yes, there can be several lambdas in a function, though I don't think this is common. Certainly it hasn't given me any problems in use, so far. But lambdas outside of definitions? I doubt very much there are any in the Emacs sources, or even in the packages. Or are you thinking about something like an explicit (defalias foo (lambda (..) ...))? > Furthermore, that info is already available to the bytecompiler, so it's > actually easier to keep that info. How are you actually going to use this information? What are you going to print in a backtrace, in particular in a batch mode backtrace where things like buttons are not useful? For that matter, what are you going to print in that C-h v example? > >> Actually, the bytecode functions can already keep the FILE info (in > >> the form of the (FILE . OFFSET) cons cell in the docstring slot of the > >> bytecode object), we just opt never to expose that FILE info to the user > >> (we only use it to fetch the actual docstring). > > That's the offset in the .elc file, though, not the source. > Yup. [ Tho now that you make me think about it, if we want to be cheap, > we could go to that OFFSET position and look around for a `^(defalias` > and that might be sufficient to give us "the surrounding definition" in > many cases :-) ] That doesn't sound systematic, or at all attractive. ;-) > >> [ Tho, admittedly, it's also that the byte-compiler only uses such > >> (FILE . OFFSET) for named functions, but it wouldn't be hard to change. ] > >> As for how/where to store the LINE+COL, I guess (aref form 5) is still > >> an option, although, maybe we should store that info alongside the > >> docstring, like we already do for the arglist. > > Well, the doc string is at (aref form 4). :-) > What I meant is that the docstring is in the `.elc` file. So the > bytecode object would be literally unchanged, it's just that the > bytes found at OFFSET inside FILE would be extended to hold: > - the docstring > - the human-readable arglist > - the LINE+COL info Don't forget, all this info would have to go into .eln files too, probably in the struct Lisp_Subr. It would be better if it were also somehow available in uncompiled lambdas, something which is needed for debugging failures in early bootstrapping. > Stefan -- Alan Mackenzie (Nuremberg, Germany).