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 08:47:30 -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="6623"; 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 13:48:43 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 1qyAeJ-0001XN-79 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 01 Nov 2023 13:48:43 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyAe5-0002K4-0i; Wed, 01 Nov 2023 08:48:29 -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 1qyAe4-0002Ju-0W for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 08:48: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 1qyAe3-0005hh-NX for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 08:48:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyAeb-00079a-KR for bug-gnu-emacs@gnu.org; Wed, 01 Nov 2023 08:49:01 -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 12:49: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.169884290227246 (code B ref 66750); Wed, 01 Nov 2023 12:49:01 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 1 Nov 2023 12:48:22 +0000 Original-Received: from localhost ([127.0.0.1]:50132 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyAdu-000751-Rl for submit@debbugs.gnu.org; Wed, 01 Nov 2023 08:48:22 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:15255) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyAdp-00074V-1j for 66750@debbugs.gnu.org; Wed, 01 Nov 2023 08:48:16 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 3D8E7441470; Wed, 1 Nov 2023 08:47:33 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1698842851; bh=aypVzC4Q4GQS6S+0zkwDpnqOIZRSZf9TAoYkCwm3EAk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Tr3U3rF2d33n8CIuMvbeT72xMhPZDg/xhKPCraxzIjMi1+lzUOsb9/kWcKPkEpVuG 1LTpIBPMRK0aQEcOksF6NVcKb8hlIk6HBeHuFhgh2bAsZP2S4eqpWkxE0+u1eojJFn B11rOxaKRQ2ZZo98XjoVeG/rd5gTihQ7CigY+UHuWy1mPNHI34x2Pvb2lJQVW2Mxqc 5XCrp2qJYRsg4Tf0iRJuCWxCeVqv0reyuRBgIq1QEzrKS/V/VxAN/CFhHxEr9MG0bq oKsoa+1eK/4S77BL9I9xUgMdEhZQ68Ao6mDj7/2f6N9feMLADyoYOkGjbzbiJXW6Lv PzRe8Pn2dzkIg== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B8B8344144B; Wed, 1 Nov 2023 08:47:31 -0400 (EDT) Original-Received: from pastel (unknown [45.72.195.71]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 8D47C1200CC; Wed, 1 Nov 2023 08:47:31 -0400 (EDT) In-Reply-To: (Alan Mackenzie's message of "Mon, 30 Oct 2023 09:44:54 +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:273599 Archived-At: Alan Mackenzie [2023-10-30 09:44:54] wrote: > Thus far, all you've done is disparage every design decision I've made > with this code, saying how you would have done it differently, without > giving any justification for why your way would be better. How am I > meant to react? 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. 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). 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. >> > 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. >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. >> Then why do you presume we'd be so stupid as to include the full >> absolute file name in there? > That falls outside the bounds of acceptable GNU mailing list language. Yes, I was aware of it. I just wasn't able to refrain from venting my frustration: criticizing my suggestion based on the fact that the full file name is too long falls squarely in the category of "strawman argument". >> > Besides which, you'd need to store all the pertinent information, the >> > filename + line + column in RAM, probably in the subr or the byte >> > coded function. >> I already told you where we'd store that info. Not in RAM. > 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. > You haven't made any attempt to justify this, to my mind, questionable > design. Hmm... I'd return the compliment :-) > Which looks like you intend to strip it out, leaving interpreted code as > a special case without the instrumentation. Yes. >> 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`. - changing the representation of functions (both bytecode and interpreted). - added runtime costs even when the feature unused (no `C-h v`, no backtraces), which is the most likely use-case. Storing the info in the docstring would fix the second and third point. Using the FILE+LINE+COL info would fix the first. >> > 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. :-( Stefan