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#66912: With `require', the byte compiler reports the wrong file for errors. Date: Sun, 10 Nov 2024 10:40:31 +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="22471"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acm@muc.de, Eli Zaretskii , 66912@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Nov 10 11:42:01 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 1tA5OH-0005bf-EY for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 10 Nov 2024 11:41:57 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tA5NX-00029m-HO; Sun, 10 Nov 2024 05:41:11 -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 1tA5NO-0001v7-Io for bug-gnu-emacs@gnu.org; Sun, 10 Nov 2024 05:41: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 1tA5NO-0008W9-1j for bug-gnu-emacs@gnu.org; Sun, 10 Nov 2024 05:41:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=From:In-Reply-To:MIME-Version:References:Date:To:Subject; bh=Cab2oo7bdD6NUXpRHEMX0KUgnlRkIVh/jT9KXFAoDVg=; b=Qv7mVb2HK6GhYC9ICXGZeV5DA1PuStJxj8KQxQlzgsCY+FvqR6SuzDrQz2l0Qz0UpDx7E5dyEny/a40jJI1tXFgRs5pJDWzxaX5WFOkgsxd8KndK7JMTOtXawUrgjslhCQ2ayixTsEG441Sp4KPGblxrvdDcSqm8aTWYYVauLgN9W1JY/X4YW4uz6cP7f4J16CSbzgCCSifPYrThRbAAB39nsvgJ8fO+LwfD/3Ht1QCFeAZ3PCoaWKSDHAu2/rg0LMLwt/dW1LojiryFVIMgsydgg2shXA9FVzKJzE2wo8kTylMFeOU2wT7Q9l9suX/FV869yQxbzYBwtekcRRua5w==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tA5NN-0002rW-T1 for bug-gnu-emacs@gnu.org; Sun, 10 Nov 2024 05:41:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alan Mackenzie Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Nov 2024 10:41: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.173123524210961 (code B ref 66912); Sun, 10 Nov 2024 10:41:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 10 Nov 2024 10:40:42 +0000 Original-Received: from localhost ([127.0.0.1]:55849 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA5N3-0002qi-IE for submit@debbugs.gnu.org; Sun, 10 Nov 2024 05:40:41 -0500 Original-Received: from mail.muc.de ([193.149.48.3]:35426) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tA5N0-0002qO-J0 for 66912@debbugs.gnu.org; Sun, 10 Nov 2024 05:40:39 -0500 Original-Received: (qmail 72809 invoked by uid 3782); 10 Nov 2024 11:40:32 +0100 Original-Received: from muc.de (pd953a71d.dip0.t-ipconnect.de [217.83.167.29]) (using STARTTLS) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 10 Nov 2024 11:40:32 +0100 Original-Received: (qmail 4193 invoked by uid 1000); 10 Nov 2024 10:40:31 -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:295174 Archived-At: Hello, Stefan. On Sat, Nov 09, 2024 at 11:45:36 -0500, Stefan Monnier wrote: > >> > OK, I see what you mean. I took it for granted that the message should > >> > be the same, regardless of whether it is reported by a debugger or by > >> > the error handler. > >> AFAIK the debugger does not emit the "error message" at all, it shows > >> the error object instead, so it's already different. > > That doesn't seem to address the point I made above at all. > Then I don't know what "the message" you're referring to. > (or are you referring to some other point you made elsewhere?) I simply meant what the user sees on the screen. If the user sees "While loading foo.el... \nWrong type argument: listp, baz" whilst doing something, then enables the debugger and repeats the action, she should see the same message at the top of the backtrace. Surely? Truncating that message can only lead to confusion. > >> And the full info would readily be available from `Vloads_in_progress_at_error`. > > Vloads_in_progress_at_error is not available to the user, being an > > internal variable. > [ I'd make it user-visible, as well Vload_in_progress, but that's not > actually relevant. ] > Even if it's not directly exposed to the user the info *is* available, > so we can offer ways to make use of it. I am proposing a single way. > > The problem with the Vloads_in_progress_at_error approach is that its > > information gets prefixed to EVERY error message which occurs while the > > debugger's recursive edit is in progress. This is not a Good Thing. > If `load-in-progress-at-error` hold (C B A), I'd make the error message > emit either nothing, or just C, or B and C, or A and B and C depending > on where in the call stack we're calling from (using the `while` loop > that compares to `load-in-progress`). > >From within the debugger, presumably `load-in-progress` would still be > (C B A), so error messages would usually display no "while loading" at > all, unless the errors themselves occur within a load of some file D, > of course. > Note that this is not just the behavior we happen to get with the hacks > I came upon along the way. It's the behavior I'm aiming for (e.g. it's > also the behavior that we'd get with the `handler-bind` approach > I advocated earlier). I'll go back and see if I can find that. Again, why do you think this is what we should aim for, rather than having the same message in the error handler and at the top of a backtrace? [ .... ] > Sorry, I meant > (equal (prefix-load-file-names > (error-message-string ERROR-OBJECT)) > (prefix-load-file-names > (error-message-string ERROR-OBJECT))) OK, that would indeed return nil if the first call to p-l-f-names was the first such call since the error occurred. > [ I assumed you had added a call to `prefix-load-file-names` in > `error-message-string`. Not sure why you didn't, but I haven't > thought very much about which option is best in this regard. ] I wasn't actually aware of the function error-message-string. Seeing as how it is called from many places (over 100), there doesn't seem to be any advantage in putting a call to prefix-load-file-names inside it. [ .... ] > Stefan -- Alan Mackenzie (Nuremberg, Germany).