From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#66750: Unhelpful text in C-h v for variables with a lambda form as value Date: Thu, 02 Nov 2023 12:09:28 +0200 Message-ID: <837cn08o13.fsf@gnu.org> References: <83il6k8yyd.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18921"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, 66750@debbugs.gnu.org, monnier@iro.umontreal.ca, stefankangas@gmail.com To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 02 11:10:42 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 1qyUev-0004hl-TJ for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Nov 2023 11:10:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyUel-0000Fg-Ia; Thu, 02 Nov 2023 06:10:31 -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 1qyUej-0000FK-UR for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 06:10: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 1qyUeh-0005AM-UR for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 06:10:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyUfG-0003UE-H2 for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 06:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Nov 2023 10:11: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.169891981913341 (code B ref 66750); Thu, 02 Nov 2023 10:11:02 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 2 Nov 2023 10:10:19 +0000 Original-Received: from localhost ([127.0.0.1]:53977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyUeY-0003T7-Sp for submit@debbugs.gnu.org; Thu, 02 Nov 2023 06:10:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34514) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyUeX-0003Ss-81 for 66750@debbugs.gnu.org; Thu, 02 Nov 2023 06:10:18 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qyUdr-0004rP-UI; Thu, 02 Nov 2023 06:09:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=hz4IxoZMwbbadnbEh7LGV7woYLQMzBkFeHdj4Ky3q2Y=; b=RLrxEJcmxVRM MRUoYa/V7LqO6QB0I2dix0qT/vQEn7R38aYms4HNYLflwodTKRsM1ixSoFLO1kQwLXelF94EuSDvc X+mKKQ5Ac+cyFqVShfhTJi1HMDLaon4s0vfc8JIY4R/xEqM/xKhf6xubXnTAwRc10PKdEVwmXNuEl ZyqnY7lpUjcQBxFxTlrXTB8HB1SaZ0tL+KPPPMEc5LphEvhIPwdi0IFHknlXpymAlCITuZ3bdDvFW J5czwTfMJmTMqrwBFsMotorHUSGdvbj6IO66G6sS5iAKYXHW46VGGeCtgTCrux3rZgvyHuIfgU7hV 8PvX2vx7rHl/9yvRTz3p5A==; In-Reply-To: (message from Alan Mackenzie on Thu, 2 Nov 2023 09:37:15 +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:273642 Archived-At: > Date: Thu, 2 Nov 2023 09:37:15 +0000 > Cc: Stefan Monnier , 66750@debbugs.gnu.org, > acorallo@gnu.org, stefankangas@gmail.com, acm@muc.de > From: Alan Mackenzie > > What Stefan seems to be proposing does not accord with his previous > paragraph. He is proposing an implementation which would preclude > extension to what he calls the "less common" cases - things like working > in edebug and interpreted code in general, amongst others. I'm not sure your conclusion above is correct. But even if it is, whether we want such extensions should be the subject of a separate dedicated discussion, after implementing what caters to the important cases, if an implementation that caters to all of them is much more complicated (which seems to be the case here). There's no reason to reject a much simpler implementation just because it doesn't support 110% of the cases. > > Alan, we are in the engineering business, where designing for the most > > common case, before adjusting the design in small ways for less common > > cases, is one of the important principles. > > Another principle is not closing off future options. That is secondary to the above. Future options might require a complete re-implementation, so the fact that the current implementation doesn't support those future extensions is not necessarily a fatal flaw. It is just one disadvantage, which should be weighed against its advantages. > We're at the stage where there's working code, which already works for > edebug, ERT backtraces, early-debug.el, and so on. So why are we > debating abstract design principles? Because having a working code doesn't necessarily mean we should be happy about it. > > And this is the usual outcome of trying to solve _ALL_ cases from the > > get-go, by focusing on the fringe ones. Premature optimization and > > all that. > > I haven't focussed on fringe cases. I've focussed on getting a uniform > implementation without special cases. The point I'm trying to make is that in your attempt to find an implementation that covers everything you entered the area of the proverbial diminishing returns, and the result is problematic in several aspects. Your objections to alternative ideas seems to come from the argument that those ideas will fail to support some rare cases, but I consider rejection of ideas on these grounds as wrong and even invalid, because it sacrifices too much for too little. > It would be nice if people actually tried out the code in practice before > criticising. So far, there's no indication anybody has done this. Why do we need to try the code before discussing its obvious implications on Emacs? The issues that Stefan is raising are crystal clear from just reading the code. > > Alan, I'd appreciate if you rethink your approach to the > > implementation with the above principles in mind. > > I don't want to implement something which will only work most of the time > for the easy to implement cases, and which precludes extension to the > general case. I'd welcome any suggestions for a mechanism which would be > capable of extension to the general case. Once again, such ideas are definitely welcome, but they are not an "over-my-dead-body" kind of requirement. > I think you've already decided not to merge feature/named-lambdas. I'm > not surprised, but it's a shame. I didn't yet make any decision, because I still hope you will agree with at least some of the arguments. Or at least agree to some kind or compromise, even if you keep your opinions. > Debugging Emacs Lisp is frequently a horrible experience, with partial > error messages which don't tell you exactly where an error occurred, > don't tell you which primitive triggered an error, and frequently give > truncated backtraces, if any at all, due to unwise condition-cases, and > so on. I disagree with "frequently" and "horrible". My experience is different, although I do sometimes need to be "creative" to catch some errors. But the existing tools, including GDB (which you for some reason seem to reject completely AFAU) and even printf-debugging usually do the job for me. So the current situation being described in such apocalyptic terms is not something I can agree with. > One of these things is having meaningless anonymous entries in > backtraces and C-h v, with no connection back to the source code. > feature/named-lambdas fixes this. Won't jumping to the exact source line where the error happened fix this better? If I have a single significant gripe against Emacs Lisp backtraces, it is that there's no way of jumping to the offending source line in each stack frame, something that is very natural to provide. Anonymous lambdas come as a very distant second or third problem, at least IME.