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#66750: Unhelpful text in C-h v for variables with a lambda form as value Date: Wed, 01 Nov 2023 14:11:33 -0400 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="32081"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 66750@debbugs.gnu.org, Andrea Corallo , Stefan Kangas To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 01 19:14:45 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 1qyFjp-000852-GV for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Nov 2023 19:14:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyFja-0007EA-5a; Wed, 01 Nov 2023 14:14: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 1qyFjZ-0007CE-03 for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 14:14:29 -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 1qyFjY-0002oX-KT for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 14:14:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyFk6-0003W4-GR for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 14:15:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 01 Nov 2023 18:15: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.169886247413462 (code B ref 66750); Wed, 01 Nov 2023 18:15:02 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 1 Nov 2023 18:14:34 +0000 Original-Received: from localhost ([127.0.0.1]:52536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyFje-0003V4-4H for submit@debbugs.gnu.org; Wed, 01 Nov 2023 14:14:34 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:26319) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyFja-0003Un-Gj for 66750@debbugs.gnu.org; Wed, 01 Nov 2023 14:14:33 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8BEC61000BC; Wed, 1 Nov 2023 14:13:50 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698862429; bh=ooZF1WE2EBESOoj4PrRJhr7LYGNEF36Rsaz2Z2izuQs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=DMW0NwHcrM1h6FRus/w6D96ZodehyZSY3BHDwapkLxVpLFMWDjul4V72MyRRA+if+ Wwl4mqIt8Kh7A59NTl4wCosni4axDmxkhFzW3hYeFa0aX+MTy0jS+nPHlhbKm4CWgD ngT7S0kxakbkV54JbYHT3cduiPbENNtBugEWuuxrl6HdBzbe/vz+EpWMFSe3XCHp1T d415jHHjM1WQnLyWy5gP/Ssat11esxVdL4SKiFEOJee7ER4mZSsGdQSQrEHNafADSX WfiHHlrknXYrPjlM50PfRIt2GBg7JEeCN+giCRmNYaIIhtYHwgsXWUe9oOw6RTYuHj HJBexG+0MIvdg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8F28F100043; Wed, 1 Nov 2023 14:13:49 -0400 (EDT) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 748A71201AF; Wed, 1 Nov 2023 14:13:49 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Wed, 1 Nov 2023 15:03:43 +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:273613 Archived-At: >> 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. Exactly. That makes you put much more emphasis on this aspect than it generally deserves. *Very* few Emacs users ever do that. > That doesn't seem relevant to bootstrapping bugs. Using gdb on part of > the bootstrap is quite difficult. GDB is my "go to" tool when I have an error during bootstrap and I find it fairly easy to use. >> 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. Note that `early-debug.el` doesn't handle "_ALL_" cases: it's only used for those cases where the normal debugger can't be used. Before catering to the same use-cases as early-debug, we should cater to the use cases of the average user/developer who's never getting close to the bootstrap. >> 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. How are you going to fix the problem without going 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. If your batch session's output is piped to an auto-reverted file in compilation-mode (mine usually is, FWIW), it's small matter of making sure the format is recognized. Still, I refuse to change the syntax of `lambda` just to make it slightly easier to debug the odd bootstrap problem. > >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. >From where I stand: - If you don't have the source code any more, then you don't have anywhere to fix the problem. - If the source code has changed, then maybe the problem has already been corrected (or modified) by that change, so there's not much point debugging it any further. So, why would you consider it to be common? What kind of scenario do you have in mind where this is sufficiently common to be worth paying much attention to it? > We clearly differ in our views of what backtraces should do. I don't know why you insist so much on backtraces. I've wished for that info in many more cases than backtraces. > Also, I think the backtrace code should be as robust as possible, you > don't seem to. I want it to be featureful, with a fallback for those rare cases when that's not an option. You provided the fallback already in `debug-early`. > I will be working on putting this file and position information into the > code. It will be tedious rather than difficult. Why would it be tedious? It should be easier than what you did because you don't need an extra arg to `lambda` and you don't need to `defining-symbol` any more. It should make the change simpler. >> > 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. I don't find this particularly important. > Your way would make it unavailable. You could tweak Edebug to add that info, thus keeping the change localized to Edebug. >> 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. Still, it changes the syntax of a very fundamental building block. That's a pretty high cost in my book compared to the benefit it brings. If you want to do that, I'd rather you keep `lambda` as before and macro-expand it to a new form that has the new syntax. Part of the cost of your change here is that it prevents future changes that might want to use a similar syntax for other purposes. IOW it "eats up namespace", tho "namespace" is not quite the right word. >> - changing the representation of functions (both bytecode and interpreted). > Don't forget the native compiled, too! That's more internal and it's currently not used for closures, so I find this part of the cost negligible. > 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. For bytecode it's still an extra field (which we have to pay for every closure we create) thus increasing memory use. Plus the incompatible change of position of the interactive form (tho I find this less of an problem). Maybe in your tests, the increase is negligible, but remember: every user will pay this tiny cost, and most of the users will never reap any benefit from it, and those who do will only do very rarely. It's a good change for us hard-core Emacs hackers, but it has to come *very* cheap because the gain is really low for other users. >> 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". Docstrings live in the `.elc` files. > 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. Probably because you think of it as a docstring only. Think of it as "out of line storage" where we can keep introspection data for which we don't want to pay *any* cost (other than disk space use) in the normal execution of code (i.e. when calling the closure or when creating the closure) such as: - documentation - human-readable arglist - source code location - debug info - a copy of the source code - ... > It seems like a kludge, and would complicate Emacs's handling, much as > the existing new code complicates it. I see it as an opportunity to clean up this kludge. Stefan