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#67455: (Record source position, etc., in doc strings, and use this in *Help* and backtraces.) Date: Sat, 30 Mar 2024 09:10:14 +0000 Message-ID: References: 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="18548"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Eli Zaretskii , 67455@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Mar 30 10:11:32 2024 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 1rqUkM-0004ew-AY for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 30 Mar 2024 10:11:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rqUju-0003cH-EM; Sat, 30 Mar 2024 05:11:02 -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 1rqUjs-0003c9-R1 for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 05:11:00 -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 1rqUjr-0002I7-S0 for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 05:11:00 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rqUjt-0000kX-KV for bug-gnu-emacs@gnu.org; Sat, 30 Mar 2024 05:11: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: Sat, 30 Mar 2024 09:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67455 X-GNU-PR-Package: emacs Original-Received: via spool by 67455-submit@debbugs.gnu.org id=B67455.17117898262757 (code B ref 67455); Sat, 30 Mar 2024 09:11:01 +0000 Original-Received: (at 67455) by debbugs.gnu.org; 30 Mar 2024 09:10:26 +0000 Original-Received: from localhost ([127.0.0.1]:43942 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqUjJ-0000iN-Gl for submit@debbugs.gnu.org; Sat, 30 Mar 2024 05:10:25 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:28692) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rqUjG-0000i6-Oy for 67455@debbugs.gnu.org; Sat, 30 Mar 2024 05:10:23 -0400 Original-Received: (qmail 28356 invoked by uid 3782); 30 Mar 2024 10:10:14 +0100 Original-Received: from acm.muc.de (p4fe15358.dip0.t-ipconnect.de [79.225.83.88]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 30 Mar 2024 10:10:14 +0100 Original-Received: (qmail 6125 invoked by uid 1000); 30 Mar 2024 09:10:14 -0000 Content-Disposition: inline In-Reply-To: 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:282337 Archived-At: Hello, Stefan. On Thu, Mar 28, 2024 at 12:25:11 -0400, Stefan Monnier wrote: [ .... ] > >> The earlier the better, in theory, but not at any cost. > > No, the earlier the better, full stop. > Please "full stop" being absolutist. We're talking about opinions and > preferences here. What you're proposing is only handling some fuctions because you think we're collectively not clever enough to maintain byte-run--posify-defining-form. This would leave Emacs inconsistent, some functions failing to be handled not for any functional reason, but because of an alleged lack of our capability. > When hitting an error, I spend more time reading the code (and modifying > it) than looking at debug output, so to me the clarity of the code is > more important than whether a few lambdas get some addition positional > info, especially since I usually know full well where those lambdas > come from. My prime method of debugging is reading code, too. But you're conflating the clarity of b-r--p-defining-f with the clarity of the code you're debugging. They're different things. The former is less important than the latter. The whole point in these changes is to give info precisely in those anonymous lambda entries in backtraces which currently contain no information. > I understand it affects us differently, but the tradeoff is real. > >> Having to write all that code within the very restrictive sublanguage > >> available before subr.el and backquote.el is a cost I don't think > >> justifies it. This is done in other functions, too. > > The cost has already been paid, by me. > Code is not "fire and forget". [ .... ] > >> But your current code in byte-run.el is a Bad Thing as well. > > What, precisely, do you find bad about it? It may be possible to improve > > it without wholesale redesign. > A lot of it is hard to read because it is constrained to a restrictive > subset of ELisp. byte-run--posify-defining-form uses the same techniques as other declare clause handlers, such as byte-run--set-interactive-only and many others. Why is b-r--p-defining-f objectionable, but not b-r--s-i-only? It was tedious rather than difficult to write, and it is tedious rather than difficult to read. > >> I'm not suggesting to drop support for lambdas loaded from source. > >> I'm saying we don't need to support it for the first N files loaded into > >> `src/emacs-bootstrap`. > > You're suggesting dropping support for many source files, where that > > support is most needed. > "Most needed" according to which criteria? The difficulty of debugging in early bootstrap compared with when further debugging tools have already been loaded. [ .... ] > Code costs by merely existing. Inconsistencies and sloppy implementation cost too. [ .... ] > Stefan -- Alan Mackenzie (Nuremberg, Germany).