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 15:55:22 +0000 Message-ID: References: <83il6k8yyd.fsf@gnu.org> <837cn08o13.fsf@gnu.org> <831qd88dt5.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="31967"; 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 16:56:59 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 1qya40-0007zq-Tf for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Nov 2023 16:56:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qya3Z-0004Zi-T2; Thu, 02 Nov 2023 11:56: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 1qya3Y-0004ZX-5H for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 11:56: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 1qya3X-0003Su-TC for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 11:56:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qya45-0007gI-VD for bug-gnu-emacs@gnu.org; Thu, 02 Nov 2023 11:57:01 -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 15:57: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.169894057029458 (code B ref 66750); Thu, 02 Nov 2023 15:57:01 +0000 Original-Received: (at 66750) by debbugs.gnu.org; 2 Nov 2023 15:56:10 +0000 Original-Received: from localhost ([127.0.0.1]:55827 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qya3G-0007f1-6O for submit@debbugs.gnu.org; Thu, 02 Nov 2023 11:56:10 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:42573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qya3B-0007eU-CM for 66750@debbugs.gnu.org; Thu, 02 Nov 2023 11:56:08 -0400 Original-Received: (qmail 90649 invoked by uid 3782); 2 Nov 2023 16:55:24 +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 16:55:23 +0100 Original-Received: (qmail 8228 invoked by uid 1000); 2 Nov 2023 15:55:22 -0000 Content-Disposition: inline In-Reply-To: <831qd88dt5.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:273655 Archived-At: Hello, Eli. On Thu, Nov 02, 2023 at 15:50:14 +0200, Eli Zaretskii wrote: > > Date: Thu, 2 Nov 2023 11:52:45 +0000 > > Cc: monnier@iro.umontreal.ca, 66750@debbugs.gnu.org, acorallo@gnu.org, > > stefankangas@gmail.com, acm@muc.de > > From: Alan Mackenzie > > > > 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? > How about if you propose a compromise with which you could live? That is difficult. What you and Stefan are objecting to is not the minor details of my patch, it's its very essence. That essence is the existence of the defining symbol, and the amendment of the three function formats to accomodate it. I could see myself replacing the defining symbol with FILE:POSITION information, but I doubt that would make the two of you happy enough. Or, maybe put this defining symbol or F:P information into the doc string somehow (including in the interpreted format) like Stefan was suggesting recently. > > 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". > This is what I call "debugging". By and off itself, such a situation > is not necessarily anywhere near "horrible". For example, it could be > that in the 'require'd file you will easily find the reference to > :autoload-end. Yes, but it takes an order of magnitude longer than if it had given the position in the required file where the error happened and had told me that it was a cadr operation which threw the error. All these oders of magnitude longer add up to hundreds of hours over the years. > I also don't necessarily see how this is relevant to the issue at > hand. It's not. Except it's all part of the same overriding topic, what I feel to be the inadequacy of Emacs's Lisp debugging tools. > > > 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. > Maybe so, but if your feature doesn't bring us closer to that goal, > then for me personally it is much less interesting. Maybe we could put no-ops into the byte compiled format, where each no-op had a position argument. But that would make Emacs a bit slower. Or we could add an extra "debugging" field to the structure which would contain the position information. As with lots of things, macros would complicate such a scheme. In the native compiled format, isn't there already a standard way of writing this info? [ .... ] -- Alan Mackenzie (Nuremberg, Germany).