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, 05 Nov 2024 18:20:03 -0500 Message-ID: References: Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17667"; 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 Wed Nov 06 00:21:50 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 1t8Srt-0004Pr-3w for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 06 Nov 2024 00:21:49 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1t8SrA-0005mJ-Uz; Tue, 05 Nov 2024 18:21:06 -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 1t8Sr9-0005m9-3X for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 18:21:03 -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 1t8Sr7-0003OW-Ta for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 18:21: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=phfztMpefG6jrqDHggwk+FeX5maalco5695W1oBM9r8=; b=viJ32J20nZnNAPT/iezOSC9alQ7XHZKtmG4eyVyXj746+MU2jsODe5EXvofPh0bfbHP94XWdgwy7YZRhxDnKWvqqAyaTiey0d1eovs3WtAheizL1hGCooO+GLXiZH0RfmaC753hjOtpgIs8V1irydnhmZRpdvhxSeFkyaEJAl31o0KnPjd2oIN09kM7tXVRTDZERgV0M19VByENjOsEke8UCi4UwpPONa3VsN1Cojpw9Y5ucBYcgG1oQ8RuW310jsq0VxhOB4xQJqKjE/IQ+M2qRSqKL++59RMFkvKPImbDiU4Ap+CVXCgLOC8XqM5kQ/CtDDI+7QwvF3tz7EcJBtA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1t8Sr7-0004ct-N8 for bug-gnu-emacs@gnu.org; Tue, 05 Nov 2024 18:21: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, 05 Nov 2024 23:21: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.173084881317719 (code B ref 66912); Tue, 05 Nov 2024 23:21:01 +0000 Original-Received: (at 66912) by debbugs.gnu.org; 5 Nov 2024 23:20:13 +0000 Original-Received: from localhost ([127.0.0.1]:38507 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8SqL-0004bi-7x for submit@debbugs.gnu.org; Tue, 05 Nov 2024 18:20:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7486) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1t8SqI-0004XH-PS for 66912@debbugs.gnu.org; Tue, 05 Nov 2024 18:20:11 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 6B886100180; Tue, 5 Nov 2024 18:20:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1730848803; bh=ueSCAanZ7VZ2D8PZxN4E7zppJI0F8UJ7r9ULqQWcxbY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=atZrNKZKVhGO3TWunQRoPN7GDUpR/5KnuGYFg4EqniE6YIdnU1XzM2IiPyPTl8v6L 18QiAtuLHrhTR/ChdaPsUv0/tGzZ4v8uNTjwmNW7ethARwGW2mXjZM8+SlImyZ/+jm yeX4E8maRCNGS2jSDC5xJ0I54yD9EJxdJ5NaYgbh57X7efRK2RIdTItax1FTf5lYG6 oqqmCRh5iguf4LZWGPZjrslER/8RGBwiJ/05svBwxhF81sjTnVg42W/MkeXh5hE9vw Nwghx7QVuVLDiABreKuG7M/YOOU9wjKiTHOmWHyAp3X+Gqg6pToLGFIbESau9JxOb9 SiGljHLmMsEew== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id B10BF100043; Tue, 5 Nov 2024 18:20:03 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A28511204EC; Tue, 5 Nov 2024 18:20:03 -0500 (EST) In-Reply-To: (Alan Mackenzie's message of "Tue, 5 Nov 2024 20:33:23 +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:294925 Archived-At: > There needs to be some mechanism for resetting this variable to Qnil, > should the error handler fail to access it. I was thinking we wouldn't bother, just like the we don't bother emptying the match-data after we used it. > Also, we need to be careful about condition-cases in debuggers, where an > error, even if handled, might overwrite Vloads_in_progress_of_last_error. Yes, we may want to locally let-bind the var to preserve it, similarly to the occasional use of `save-match-data`. > However, signal_or_quit is supposed to be a general low-level function, > and it doesn't seem ideal to bloat it out with special purpose tests. Indeed, which is also why I was pointing out that the thing could be generalized to other context information, so we don't get fixated on `load`. > Another possible problem with this wild idea is that debuggers, or parts > of them, might need to be autoloaded. This shouldn't be a problem with > edebug.el, where the file would be loaded to be able to instrument a > form, but I don't think anything's loading debug.el before it gets used. If the let-binding that preserves the new var is performed around the call to the debugger (rather than being performed inside the debugger itself), we should be OK. > I think your idea might be better than my current patch, but I doubt > it's going to be much simpler. The thing I like is that it should be a better replacement for `Vsignaling_function` (which is currently a very low-tech feature which works only half the time). >> > I think I would agree, but this would be difficult for .el[cn] files. >> > How about giving the line number just for .el files, something like: >> That's what I meant, yes. > OK, I'll think about that, but after we've got the basics (see above) > sorted out for this bug. Yes, there's no hurry. Stefan