From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#66912: With `require', the byte compiler reports the wrong file for errors. Date: Tue, 12 Nov 2024 10:38:47 -0500 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39132"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 66912@debbugs.gnu.org To: Alan Mackenzie Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 12 16:40:22 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 1tAt09-000A1K-NW for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 12 Nov 2024 16:40:22 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tAszs-0007dV-Cm; Tue, 12 Nov 2024 10:40:04 -0500 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 1tAszq-0007ZI-Be for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2024 10:40:02 -0500 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 1tAszq-0007o6-2E for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2024 10:40:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=Nz6kzhcj8zOWhxYK9S9s2R0OmjtZgJIqnMAATGKfu80=; b=P2KCe4EpfhnCPEsWk198WY5FKXjUPk9yNUMZOeB/IPtxNUL3PpCjpZ3fBlNXCHqmppxpLqt+EoJ2y75GT05AxFGI/UQ97viVO4ArdrRNq804Oex6fJmhXUPaRx8aZWZCa/owlDBKYrbMiqKTviikVI10oPV4XddzuGDOlH382V9QzwXdytRS3OIFXlKAZivctJD7bfn+blBangSH62bb92wh5allb79GdA8RibUSW2q45hplfxS2yry/PG/cbGViOC2GjSUu1I0dfSoIXHqZbKhmSIXIp/IeBhaB3r9ZgMjo6VZ2rgWvlnEQ+tY0+g6XaNYCvkzJPeFiaQJ6+b6yhw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tAszp-0006Oi-Tw for bug-gnu-emacs@gnu.org; Tue, 12 Nov 2024 10:40:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Nov 2024 15:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66912 X-GNU-PR-Package: emacs Original-Received: via spool by 66912-submit@debbugs.gnu.org id=B66912.173142594324459 (code B ref 66912); Tue, 12 Nov 2024 15:40:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 12 Nov 2024 15:39:03 +0000 Original-Received: from localhost ([127.0.0.1]:38943 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAsys-0006MH-JX for submit@debbugs.gnu.org; Tue, 12 Nov 2024 10:39:03 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:37602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tAsyr-0006Lt-F6 for 66912@debbugs.gnu.org; Tue, 12 Nov 2024 10:39:02 -0500 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 214C944475D; Tue, 12 Nov 2024 10:38:50 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1731425928; bh=49B++KYDKW/xb41cKHHRBgUdjFWrK2oWW6rRGTS3izU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=MzBi6lkurnt3+6rzb/yfLU2sxB/p0OtddMYqsB6wfpn4xSQu9tyayVqnsWsL3oTwO +/QVOmUcfxihFo6Z86p2cWFSOEQsxPs4yKcynQioMjzHGH12JmeMSOXxnyejysqOXi M85O+EiaCD1hCYyPoiD3WyAn6aTrs3QN2KnmsybegvGKewIRqEObNgd12QdfWhCoKd USJk16pwhpannBE7oynLnBvgmv0UJ4Kw+bsfFyTtssi8xu6MSviv/m5wkUUhAIf1Gn eU/XCsBcL/hC6wLWQ3Ehxl3AnBAZLRDF5bBbbHrzzzO/xGQZFQgtHcoyCRdnW4pX8/ jGrcTqJej7wwA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9976A444757; Tue, 12 Nov 2024 10:38:48 -0500 (EST) Original-Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 6BA4912062E; Tue, 12 Nov 2024 10:38:48 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Tue, 12 Nov 2024 14:53:56 +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:295246 Archived-At: > OK, so you were using "the point in the chain where we catch the > error", which is of no interest to the user, as a proxy for how and > where an error message gets displayed. I conflate the two, yes. > I thought we were agreed that the "A =3D> B =3D> compile =3D> C =3D> D" w= as > vanishingly rare and probably doesn't occur at all in the Emacs sources. I like to think of such corner cases because it gives me more clarity about the general case. If I focus only on the scenario at hand it's all too easy to design something that doesn't work well in the general case. > In that case, why are you giving it priority over the other concerns > (such as consistency of messages displayed to the user) that I have > raised? Because I don't see the benefit of using "consistent" messages when the circumstances are very different. > Would you please clarify whether you are opposed to outputting the > information (about the stack of files being loaded) in the debugger > case, or are merely indifferent about it. I'm indifferent about it. But I do care about the debugger showing me the error *object* rather than merely the error *message*. > It is true that Emacs error messages are typically poor in the extreme, > in that they fail to identify the pertinent command, buffer, hook, or > variable. I have been trying to improve this for several years, with > mixed success. The thing about loading is that it is frequently > recursive, typically by the function `require'. Being told which file > the failing Lisp came from is as good as saying which buffer, and likely > better in batch mode. That's why I'm thinking of generalizing the `load-in-progress-at-error` into a `dynamic-context-at-error` where we could stash arbitrarily more information. Ideally, error objects would come with a full backtrace, from which we could extract the stack of pending loads, the name of the current command, or process filter, or hooks, ... [ In SML/NJ, exception objects keep a reference to the "stack" for that purpose, but of course, that's easy for them because they heap allocate their "stack", so it's a simple matter of keeping a reference, whereas we'd have to copy our "stack", which could slow down `signal` significantly. ] >> > I think it would be consistent to display "While loading..." the same >> > in both cases. > >> To be honest, I don't see much value in displaying "while loading" in >> the echo area in general. > > To be frank, displaying nothing but > > Wrong type argument: integer-or-marker-p, nil > > to the user is insulting. Agreed. At the same time, it corresponds to Python dumping a backtrace onto the unsuspecting user, or C crashing down with a core dump, so I think we're in good company. IOW when the end user sees such an error message, it means we have a bug in the ELisp code somewhere. The bug is either in that we should not trigger this error, or that we should catch it and turn it into an error that's meaningful in the context of the command where it's executed. Note that in presence of such a bug, adding "while loading A" won't really help. The only two behaviors that would help would be either to drop into the debugger (so as to help diagnose/find/fix the bug), or to emit a message explaining to the user that they found a bug (and maybe try and help them submit a bug report). Dropping into the debugger is what we get with `debug-on-error`, but I don't think we can enable it by default, because it's a bit too delicate to use for some users. Maybe we should improve that. > Informing the user which file the error occurred in, though far from > ideal, is significantly better than not doing so. IME, the above kind of error usually happens outside of loading files, so bug#66912 will almost never make a difference for that kind of error. >> I'm not opposed to it, but the only case where I know it could be >> helpful is during compilation (which I'm mostly interested to see it >> in the compilation buffer). > In this case, the error message is indeed displayed in *Compile-Log*. =F0=9F=99=82 Stefan