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: Wed, 1 Nov 2023 15:03:43 +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="31486"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66750@debbugs.gnu.org, Andrea Corallo , Stefan Kangas To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 01 16:04:50 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 1qyCm0-00080r-BJ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Nov 2023 16:04:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyCli-0003qM-PK; Wed, 01 Nov 2023 11:04:30 -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 1qyClg-0003qC-5O for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 11:04:28 -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 1qyClf-0007VY-Tn for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 11:04:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyCmD-0005lm-SO for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 11:05:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2023 15:05:01 +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.169885107422136 (code B ref 66750); Wed, 01 Nov 2023 15:05:01 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 1 Nov 2023 15:04:34 +0000 Original-Received: from localhost ([127.0.0.1]:52177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyClm-0005kx-1A for submit@debbugs.gnu.org; Wed, 01 Nov 2023 11:04:34 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:53183) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyClg-0005kd-5V for 66750@debbugs.gnu.org; Wed, 01 Nov 2023 11:04:32 -0400 Original-Received: (qmail 6986 invoked by uid 3782); 1 Nov 2023 16:03:47 +0100 Original-Received: from acm.muc.de (p4fe15848.dip0.t-ipconnect.de [79.225.88.72]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 01 Nov 2023 16:03:47 +0100 Original-Received: (qmail 31458 invoked by uid 1000); 1 Nov 2023 15:03:43 -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:273606 Archived-At: Hello, Stefan. On Wed, Nov 01, 2023 at 08:47:30 -0400, Stefan Monnier wrote: > Alan Mackenzie [2023-10-30 09:44:54] wrote: [ .... ] > Thanks for putting into words how I feel :-) :-) > > Not yet. Putting complicated stuff into backtrace code is a bad idea - > > look what happened when cl-print got put into debug-early.el. Bugs. > Bootstrap problems are rare, and difficult to predict, so we fix them in > a reactive way. Debugging a bootstrap is generally more difficult. I'm fully aware of this, having spent a significant part of the last few years doing just that. I aim to make it easier, as I have already done to a certain degree. > That's also true when trying to debug GDB (the usual answer is to use > another GDB, and in Emacs you can do the same: debug from another > debugger, such as GDB, rather than from the built-in debugger). That doesn't seem relevant to bootstrapping bugs. Using gdb on part of the bootstrap is quite difficult. Using edebug is not possible, as far as I'm aware. > We shouldn't design the featureset for the corner case of when the > bootstrap fails, because it is a very small fraction of the use-cases, > that 99.99% of Emacs users never face. We should design the feature set to handle _ALL_ cases, including that of bootstrapping. That's why I wrote debug-early.el, for example; it's proved its worth, certainly for me personally. > >> > Forcing a user to look somewhere else for pertinent information can > >> > only increase that level of stress. > >> Any concrete evidence to back this claim? > > Of course not. Just as you've got no evidence to back up the contrary. > Fist, I did not make a claim to the contrary, so the burden of proof is > not on me. This said, I believe there is ample evidence out there, > because all the programming tools I've ever used try first and foremost > to let you jump to the corresponding source code. The source code is > what programmers are familiar with, so being able to jump from the > backtrace to the corresponding source code is generally the best known > way to help the user find the pertinent info. Even better is if the relevant information is present on the screen or in the backtrace without having to jump to the source code. This is the point of the defining symbol. The "jumping" is only straightforward from a running Emacs session. From a batch mode backtrace (e.g. from bootstrapping or ERT), it is much more cumbersome. > >From the FILE+LINE+COL info the user can recover the info your patch > provides, but the reverse is generally not true. Of course, there is > the exception of when the source code has been changed or is missing or > somesuch, but I don't think we should consider those cases when > designing the featureset either, because here as well, this is expected > to be a fringe case. I would expect it to be quite common. We clearly differ in our views of what backtraces should do. You seem to want them only to cover the most usual cases, I want it to cover all cases, or as many as possible when all is not possible. Also, I think the backtrace code should be as robust as possible, you don't seem to. Anyhow, I now see you are correct in saying that we need file and position information. I've scanned the sources for uses of lambda at the top level, and there are functions such as mapc, define-key, ... which have no symbol associated with them that could be used as the defining symbol. I will be working on putting this file and position information into the code. It will be tedious rather than difficult. [ .... ] > > So with all the extra complexity you want to add, you'll risk getting a > > recursive error and recursive backtrace. > I want the better info, even if that means a slight increase in > complexity and the associated risk that I have to go and fix a bug in > that code next year, yes. Debugging tools are a special case: if they stop working, the normal means of diagnosing bugs don't work on them. Thus they should be robust. [ .... ] > > Which looks like you intend to strip it [debugging instrumentation] > > out, leaving interpreted code as a special case without the > > instrumentation. > Yes. OK, we have to disagree on this. For example typing d in edebug to get a backtrace should, in my view, show that info in the backtrace. Your way would make it unavailable. > >> So it'll always be a best effort, where we try and cover the > >> important cases. > > Which is a good deal better than the current state of affairs. > But as it currently stands, it comes at some costs: > - changing the syntax of `lambda`. lambda in the bulk of the sources remains unchanged. Only for very occasional cases has the syntax been enhanced. > - changing the representation of functions (both bytecode and interpreted). Don't forget the native compiled, too! Only the change to interpreted code is non-trivial. For the compiled code, there has simply been an extra field inserted at or near the end of the function structures. > - added runtime costs even when the feature unused (no `C-h v`, no > backtraces), which is the most likely use-case. There are no added runtime costs beyond the unmeasurably minute. I've compared before and after timings, and the differences, such as they were, were much less than 1% and swamped by the random variation in timings anyway. > Storing the info in the docstring would fix the second and third point. > Using the FILE+LINE+COL info would fix the first. I don't know what you mean by "docstring". You could mean either in the ..elc/.eln file or in the function structure or both. I don't see docstring storage as a very good idea. It seems like a kludge, and would complicate Emacs's handling, much as the existing new code complicates it. > >> > I still believe that the defining symbol scheme is the most practical > >> > way of conveying the needed extra information to the user. > >> Obviously. > >> > Otherwise I would have hacked something different. ;-) > >> I don't think that's how it works, sadly. > > What are you talking about with "that"? > I have the impression that you're defending your design because that's > what you've coded. :-( Only partly. Mainly it was because I thought these things out at an early stage of development. > Stefan -- Alan Mackenzie (Nuremberg, Germany).