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: Thu, 2 Nov 2023 09:37:15 +0000 Message-ID: References: <83il6k8yyd.fsf@gnu.org> 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="8468"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, 66750@debbugs.gnu.org, Stefan Monnier , acm@muc.de, stefankangas@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Nov 02 10:37: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 1qyU93-0001yX-5M for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Nov 2023 10:37:45 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyU8o-0006Q3-Nn; Thu, 02 Nov 2023 05:37: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 1qyU8m-0006Ps-0d for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 05:37: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 1qyU8l-0006lp-PM for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 05:37:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyU9K-0008QS-D8 for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 05:38: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: Thu, 02 Nov 2023 09:38: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.169891788032380 (code B ref 66750); Thu, 02 Nov 2023 09:38:02 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 2 Nov 2023 09:38:00 +0000 Original-Received: from localhost ([127.0.0.1]:53924 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyU9H-0008QB-Tc for submit@debbugs.gnu.org; Thu, 02 Nov 2023 05:38:00 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:30936) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyU9F-0008Py-FH for 66750@debbugs.gnu.org; Thu, 02 Nov 2023 05:37:58 -0400 Original-Received: (qmail 63388 invoked by uid 3782); 2 Nov 2023 10:37:16 +0100 Original-Received: from acm.muc.de (p4fe158b7.dip0.t-ipconnect.de [79.225.88.183]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 02 Nov 2023 10:37:16 +0100 Original-Received: (qmail 3227 invoked by uid 1000); 2 Nov 2023 09:37:15 -0000 Content-Disposition: inline In-Reply-To: <83il6k8yyd.fsf@gnu.org> 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:273640 Archived-At: Hello, Eli. On Thu, Nov 02, 2023 at 08:13:30 +0200, Eli Zaretskii wrote: > > Cc: 66750@debbugs.gnu.org, Andrea Corallo , > > Stefan Kangas > > Date: Wed, 01 Nov 2023 18:46:24 -0400 > > From: Stefan Monnier via "Bug reports for GNU Emacs, > > the Swiss army knife of text editors" > > >> 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. > > > I disagree. I don't understand why you want to split off (some of) "the > > > use cases of the average user" and only handle those cases. > > I don't. Instead I'm saying we should first and foremost design the > > functionality for the most common case. And *then* see what it takes > > to extend it to other cases. > Agreed. 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. > 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. Stefan wants partly to implement this feature in a way which could not be extended to interpreted code, I think. He has not given any indication of having thought about a mechanism to do this; just "we can think about that later, perhaps". 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? > > > My intention is to handle _ALL_ cases, and you find this objectionable > > > for some reason. > > Because your focus on the fringe cases has negative impacts on the > > more common case. What are these negative impacts? Stefan has alleged negative impacts, but has not done any measurements to demonstrate them, as far as I can make out. > 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. It hasn't been easy, but I think I've succeeded. 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. > 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. I think you've already decided not to merge feature/named-lambdas. I'm not surprised, but it's a shame. 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. 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. -- Alan Mackenzie (Nuremberg, Germany).