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 11:52:45 +0000 Message-ID: References: <83il6k8yyd.fsf@gnu.org> <837cn08o13.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="35291"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, 66750@debbugs.gnu.org, monnier@iro.umontreal.ca, 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 12:54:53 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 1qyWHl-0008sE-FH for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Nov 2023 12:54:53 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qyWGR-0004dg-Rr; Thu, 02 Nov 2023 07:53:32 -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 1qyWGN-0004d7-Kp for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 07:53:27 -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 1qyWGN-0000nI-Ch for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 07:53:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qyWGw-0000cl-9P for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 07:54: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 11:54: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.16989260182366 (code B ref 66750); Thu, 02 Nov 2023 11:54:02 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 2 Nov 2023 11:53:38 +0000 Original-Received: from localhost ([127.0.0.1]:54064 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyWGU-0000c2-5Y for submit@debbugs.gnu.org; Thu, 02 Nov 2023 07:53:38 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:34902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qyWGO-0000bl-3i for 66750@debbugs.gnu.org; Thu, 02 Nov 2023 07:53:32 -0400 Original-Received: (qmail 16184 invoked by uid 3782); 2 Nov 2023 12:52:46 +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 12:52:46 +0100 Original-Received: (qmail 4434 invoked by uid 1000); 2 Nov 2023 11:52:45 -0000 Content-Disposition: inline In-Reply-To: <837cn08o13.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:273649 Archived-At: Hello, Eli. On Thu, Nov 02, 2023 at 12:09:28 +0200, Eli Zaretskii wrote: > > 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. Implementing the "simpler" version which blocks extensions would be wasted effort if we decide we want those extensions. In practice, what is likely to happen is that the extensions would never be implemented. Surely these are central questions which should be answered before embarking on a restricted implementation. (OK, I can see the irony here.) > > > 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. Perhaps a less heated comparison of feature/named-lambdas's advantages with its disadvantages would be beneficial, here. > > 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. Really? Would you be happier if this code didn't work, or didn't exist? > > > 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. What would we be sacrificing if we were to merge this feature? > > 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. One of the issues that Stefan raised was that the defining symbol in "thousands" of closures resulting from a single command would be an unacceptable "waste" of storage. I don't think this would be the case. This is something capable of measurement, something I would expect Stefan to do to back up his case. > > > 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. Such ideas haven't been forthcoming in the last day or two. > > 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 > of compromise, even if you keep your opinions. I don't think Stefan is talking about a compromise. He's talking about discarding my changes entirely, and starting again from scratch, working to design principles and with design goals I disagree with. How is that a compromise? Or had you in mind something less drastic? > > 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. I use gdb, not as fluently as you do, but I use it. But debugging Lisp with gdb doesn't seem natural and isn't easy. And yes, I've put printf (literally printf) into C code quite a bit, too. A couple of days ago I got the error message: emacs-lisp/eieio.el:55:2: Error: Wrong type argument: listp, :autoload-end At the indicated file position there was just a `require' form. So there was no information about where the error happened, what detected the error, or what function or what variable gave or had the value :autoload-end. It says little more than "there was an error". This is what I mean by "horrible". In this case I was able to sort it out relatively quickly from examining my recent changes, but that's not always the case. This is typical of the quality of error messages which Emacs produces, in my experience. I'd like to improve this. > > 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? It would be a different solution to a slightly different problem. Just seeing a file name and location is less informative than seeing the defining symbol, and forces the user to take action to get more information. But I'm looking at putting this facility into the code too, after comments from Mattias (in July) and Stefan. > 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. This would be more difficult to implement. We currently have in Emacs no connection between our execution point and our source code, beyond the symbols with position used in compilation. > Anonymous lambdas come as a very distant second or third problem, at > least IME. They've been a problem for me, at least. That's why I set about solving it. And being of a lower priority is no reason to reject an existing fix. -- Alan Mackenzie (Nuremberg, Germany).