From unknown Sat Aug 16 15:58:24 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#9463 <9463@debbugs.gnu.org> To: bug#9463 <9463@debbugs.gnu.org> Subject: Status: 24.0.50; Errors should not be continuable Reply-To: bug#9463 <9463@debbugs.gnu.org> Date: Sat, 16 Aug 2025 22:58:24 +0000 retitle 9463 24.0.50; Errors should not be continuable reassign 9463 emacs submitter 9463 Helmut Eller severity 9463 normal tag 9463 notabug wontfix thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 08:06:04 2011 Received: (at submit) by debbugs.gnu.org; 8 Sep 2011 12:06:04 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1dMm-00056j-Io for submit@debbugs.gnu.org; Thu, 08 Sep 2011 08:06:04 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1dMh-00056Z-DN for submit@debbugs.gnu.org; Thu, 08 Sep 2011 08:05:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1dIh-0007EX-NF for submit@debbugs.gnu.org; Thu, 08 Sep 2011 08:01:56 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, T_DKIM_INVALID, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:50222) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1dIh-0007ET-IF for submit@debbugs.gnu.org; Thu, 08 Sep 2011 08:01:47 -0400 Received: from eggs.gnu.org ([140.186.70.92]:34180) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1dId-0004IH-Km for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 08:01:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1dIU-0007CP-19 for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 08:01:43 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:57745) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1dIT-0007CD-St for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 08:01:33 -0400 Received: by fxg9 with SMTP id 9so1777490fxg.0 for ; Thu, 08 Sep 2011 05:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:subject:date:message-id:user-agent:mime-version :content-type; bh=tcgxD4wbOQw/ErkrI/v1q/ozSlyA0G6IQXLQvaZmmeE=; b=p8QmLyFhHkRsFyRi1Pwofm6wqH70kaSTF1FT011JwZ/ldfZxEFbBsoXlUG1RX9nzK2 sTVXoSJXBfC23ew6ZJO/xBCqQR7wJKntq8pDE1Z6DTwp6bOt1dZ4xALd7aqc0FPIN2Pp wuvUYaH0W+j2M5ME3hS7H7nQpjwInjUASp3dA= Received: by 10.223.23.67 with SMTP id q3mr167522fab.82.1315483292528; Thu, 08 Sep 2011 05:01:32 -0700 (PDT) Received: from ix (dial-176163.pool.broadband44.net [212.46.176.163]) by mx.google.com with ESMTPS id d25sm1289052fak.7.2011.09.08.05.01.30 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 08 Sep 2011 05:01:31 -0700 (PDT) Received: from helmut by ix with local (Exim 4.72) (envelope-from ) id 1R1dIR-0005K9-8V for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 14:01:31 +0200 From: Helmut Eller To: bug-gnu-emacs@gnu.org Subject: 24.0.50; Errors should not be continuable Date: Thu, 08 Sep 2011 14:01:31 +0200 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.4 (-----) emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' enters the debugger. Pressing c somehow manages to continue. That make no sense to me. The debugger should instead not continue and say that errors are not continuable. In GNU Emacs 24.0.50.4 (i686-pc-linux-gnu, GTK+ Version 2.20.1) of 2011-09-05 on ix Windowing system distributor `The X.Org Foundation', version 11.0.10707000 configured using `configure '--enable-asserts' '--enable-checking' '--with-gif=no' '--with-gnutls=no' 'CFLAGS=-g3 -O0'' From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 13:51:59 2011 Received: (at 9463) by debbugs.gnu.org; 8 Sep 2011 17:51:59 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1ilb-0003KW-Fg for submit@debbugs.gnu.org; Thu, 08 Sep 2011 13:51:59 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1ilW-0003KB-5i for 9463@debbugs.gnu.org; Thu, 08 Sep 2011 13:51:57 -0400 Received: from ceviche.home (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p88HlLue018537; Thu, 8 Sep 2011 13:47:23 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 1E3676643B; Thu, 8 Sep 2011 09:31:40 -0400 (EDT) From: Stefan Monnier To: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Message-ID: References: Date: Thu, 08 Sep 2011 09:31:40 -0400 In-Reply-To: (Helmut Eller's message of "Thu, 08 Sep 2011 14:01:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3974=0 X-NAI-Spam-Version: 2.2.0.9286 : core <3974> : streams <679767> : uri <954557> X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' > enters the debugger. Pressing c somehow manages to continue. That make > no sense to me. The debugger should instead not continue and say > that errors are not continuable. "c" in errors now "continues" in the sense of "do what would have happened if the debugger had not been called". I.e. it will actually signal the error which can then be caught by condition-cases further up the stack, .... I.e. it's very similar to what happens with "q", but is often cleaner. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 14:17:28 2011 Received: (at submit) by debbugs.gnu.org; 8 Sep 2011 18:17:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1jAG-0005Fz-H2 for submit@debbugs.gnu.org; Thu, 08 Sep 2011 14:17:28 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1jAD-0005Fq-7z for submit@debbugs.gnu.org; Thu, 08 Sep 2011 14:17:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1j6H-0006RW-Au for submit@debbugs.gnu.org; Thu, 08 Sep 2011 14:13:25 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:55079) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1j6H-0006RQ-8y for submit@debbugs.gnu.org; Thu, 08 Sep 2011 14:13:21 -0400 Received: from eggs.gnu.org ([140.186.70.92]:60355) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1j6G-0005c3-8f for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 14:13:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1j6C-0006QW-C1 for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 14:13:20 -0400 Received: from lo.gmane.org ([80.91.229.12]:60954) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1j6C-0006QS-6w for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 14:13:16 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1j6A-0006zv-Rb for bug-gnu-emacs@gnu.org; Thu, 08 Sep 2011 20:13:14 +0200 Received: from dial-176163.pool.broadband44.net ([212.46.176.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Sep 2011 20:13:14 +0200 Received: from eller.helmut by dial-176163.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 08 Sep 2011 20:13:14 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Thu, 08 Sep 2011 20:13:05 +0200 Lines: 20 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dial-176163.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:loZhWqb9mN7wOMgnkPGnStrX8e4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.4 (-----) * Stefan Monnier [2011-09-08 13:31] writes: >> emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' >> enters the debugger. Pressing c somehow manages to continue. That make >> no sense to me. The debugger should instead not continue and say >> that errors are not continuable. > > "c" in errors now "continues" in the sense of "do what would have > happened if the debugger had not been called". I.e. it will actually > signal the error which can then be caught by condition-cases further up > the stack, .... I.e. it's very similar to what happens with "q", but is > often cleaner. I think the "do what would have happened if the debugger had not been called" thing should be a different command, like resignal or abort. c should only continue from truly continuable situations, like breakpoints. Helmut From debbugs-submit-bounces@debbugs.gnu.org Thu Sep 08 22:27:13 2011 Received: (at 9463) by debbugs.gnu.org; 9 Sep 2011 02:27:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1qoD-0004Ju-Dj for submit@debbugs.gnu.org; Thu, 08 Sep 2011 22:27:13 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1qoB-0004Jo-R3 for 9463@debbugs.gnu.org; Thu, 08 Sep 2011 22:27:12 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHJ3aU64rwMJ/2dsb2JhbABDqAN5gUYBAQQBViMFCws0EhQYDSSICLhNhm0EoCSEQA X-IronPort-AV: E=Sophos;i="4.68,353,1312171200"; d="scan'208";a="135261104" Received: from 184-175-3-9.dsl.teksavvy.com (HELO ceviche.home) ([184.175.3.9]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 08 Sep 2011 22:23:09 -0400 Received: by ceviche.home (Postfix, from userid 20848) id 6A489660B6; Thu, 8 Sep 2011 22:23:09 -0400 (EDT) From: Stefan Monnier To: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Message-ID: References: Date: Thu, 08 Sep 2011 22:23:09 -0400 In-Reply-To: (Helmut Eller's message of "Thu, 08 Sep 2011 20:13:05 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) >>> emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' >>> enters the debugger. Pressing c somehow manages to continue. That make >>> no sense to me. The debugger should instead not continue and say >>> that errors are not continuable. >> >> "c" in errors now "continues" in the sense of "do what would have >> happened if the debugger had not been called". I.e. it will actually >> signal the error which can then be caught by condition-cases further up >> the stack, .... I.e. it's very similar to what happens with "q", but is >> often cleaner. > I think the "do what would have happened if the debugger had not been > called" thing should be a different command, like resignal or abort. Why? When the debugger is called in a non-error case, the "c" does just that "do whatever would have happened if the debug call had no taken place". > c should only continue from truly continuable situations, like > breakpoints. Again: why? Stefan PS: The change you seem to dislike is a bug-fix in my opinion, and it has fixed a few real problems (e.g. when you enter the debugger from within a minibuffer, you can now continue your minibuffer operation, whereas earlier you could only abort back to the top-level). From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 02:57:29 2011 Received: (at submit) by debbugs.gnu.org; 9 Sep 2011 06:57:29 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1v1l-0005qV-6Y for submit@debbugs.gnu.org; Fri, 09 Sep 2011 02:57:29 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1v1h-0005qN-CX for submit@debbugs.gnu.org; Fri, 09 Sep 2011 02:57:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1uxl-000765-RX for submit@debbugs.gnu.org; Fri, 09 Sep 2011 02:53:22 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:44811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1uxl-000761-Q2 for submit@debbugs.gnu.org; Fri, 09 Sep 2011 02:53:21 -0400 Received: from eggs.gnu.org ([140.186.70.92]:59415) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1uxk-00040L-Tn for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 02:53:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1uxk-00075r-2X for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 02:53:20 -0400 Received: from lo.gmane.org ([80.91.229.12]:41529) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1uxj-00075j-PC for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 02:53:20 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1uxg-0002Y4-Ev for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 08:53:16 +0200 Received: from dial-176163.pool.broadband44.net ([212.46.176.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 08:53:16 +0200 Received: from eller.helmut by dial-176163.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 08:53:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Fri, 09 Sep 2011 08:53:02 +0200 Lines: 58 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dial-176163.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:vs9h58g8pzRmY1G6J9AzXROgF+8= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.4 (-----) * Stefan Monnier [2011-09-09 02:23] writes: >>>> emacs -Q -eval '(let ((debug-on-error t)) (error "foo"))' >>>> enters the debugger. Pressing c somehow manages to continue. That make >>>> no sense to me. The debugger should instead not continue and say >>>> that errors are not continuable. >>> >>> "c" in errors now "continues" in the sense of "do what would have >>> happened if the debugger had not been called". I.e. it will actually >>> signal the error which can then be caught by condition-cases further up >>> the stack, .... I.e. it's very similar to what happens with "q", but is >>> often cleaner. >> I think the "do what would have happened if the debugger had not been >> called" thing should be a different command, like resignal or abort. > > Why? 1. Why not? > When the debugger is called in a non-error case, the "c" does just > that "do whatever would have happened if the debug call had no taken place". 2. it's an incompatible change 3. it's frustrating when people introduce DWIM-ish features when my expectations are completely different > >> c should only continue from truly continuable situations, like >> breakpoints. > > Again: why? 4. it's easy to accidentally press c when using d and c multiple times 5. I have already lost valuable information (and time) because of this too eager stack unwinding. 6. there is nothing wrong with the traditional distinction between continuable and non-continuable situations > > > Stefan > > PS: The change you seem to dislike is a bug-fix in my opinion, and it has > fixed a few real problems It introduced a new bug: r can now be used in every situation. > (e.g. when you enter the debugger from within > a minibuffer, you can now continue your minibuffer operation, whereas > earlier you could only abort back to the top-level). You could do that just as well with a separate resignal command. Helmut From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 03:15:14 2011 Received: (at 9463) by debbugs.gnu.org; 9 Sep 2011 07:15:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1vIv-0007H6-Tb for submit@debbugs.gnu.org; Fri, 09 Sep 2011 03:15:14 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1vIs-0007At-Ek for 9463@debbugs.gnu.org; Fri, 09 Sep 2011 03:15:11 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LR800B00UDUBF00@a-mtaout22.012.net.il> for 9463@debbugs.gnu.org; Fri, 09 Sep 2011 10:10:44 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.126.9.62]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LR800B9UULV4O70@a-mtaout22.012.net.il>; Fri, 09 Sep 2011 10:10:44 +0300 (IDT) Date: Fri, 09 Sep 2011 10:10:49 +0300 From: Eli Zaretskii Subject: Re: bug#9463: 24.0.50; Errors should not be continuable In-reply-to: X-012-Sender: halo1@inter.net.il To: Stefan Monnier Message-id: <83vct25gxy.fsf@gnu.org> References: X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org, eller.helmut@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Stefan Monnier > Date: Thu, 08 Sep 2011 22:23:09 -0400 > Cc: 9463@debbugs.gnu.org > > > I think the "do what would have happened if the debugger had not been > > called" thing should be a different command, like resignal or abort. > > Why? When the debugger is called in a non-error case, the "c" does just > that "do whatever would have happened if the debug call had no taken place". > > > c should only continue from truly continuable situations, like > > breakpoints. > > Again: why? I agree with Stefan. The current operation of `c' is consistent with what other debuggers do in this situation. For example, when GDB catches a fatal signal, typing `c' will simply let the program continue with the signal, which may mean it will crash. From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 03:41:28 2011 Received: (at submit) by debbugs.gnu.org; 9 Sep 2011 07:41:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1viH-0000VQ-Lu for submit@debbugs.gnu.org; Fri, 09 Sep 2011 03:41:28 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1viC-0000VH-NX for submit@debbugs.gnu.org; Fri, 09 Sep 2011 03:41:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1veG-0005ka-UH for submit@debbugs.gnu.org; Fri, 09 Sep 2011 03:37:17 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:33132) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1veG-0005kW-QO for submit@debbugs.gnu.org; Fri, 09 Sep 2011 03:37:16 -0400 Received: from eggs.gnu.org ([140.186.70.92]:36760) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1veF-0006DG-SG for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 03:37:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1veE-0005kK-Rs for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 03:37:15 -0400 Received: from lo.gmane.org ([80.91.229.12]:42756) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1veE-0005kE-MF for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 03:37:14 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1veD-0003of-HA for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 09:37:13 +0200 Received: from dial-176163.pool.broadband44.net ([212.46.176.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 09:37:13 +0200 Received: from eller.helmut by dial-176163.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 09:37:13 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Fri, 09 Sep 2011 09:36:59 +0200 Lines: 32 Message-ID: References: <83vct25gxy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dial-176163.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:mumyTBj34yosZFFeHD630xoyevg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.4 (-----) * Eli Zaretskii [2011-09-09 07:10] writes: >> From: Stefan Monnier >> Date: Thu, 08 Sep 2011 22:23:09 -0400 >> Cc: 9463@debbugs.gnu.org >> >> > I think the "do what would have happened if the debugger had not been >> > called" thing should be a different command, like resignal or abort. >> >> Why? When the debugger is called in a non-error case, the "c" does just >> that "do whatever would have happened if the debug call had no taken place". >> >> > c should only continue from truly continuable situations, like >> > breakpoints. >> >> Again: why? > > I agree with Stefan. The current operation of `c' is consistent with > what other debuggers do in this situation. For example, when GDB > catches a fatal signal, typing `c' will simply let the program > continue with the signal, which may mean it will crash. What's the point of being compatible with GDB but not with previous versions of the Elisp debugger or for that matter with other Lisp debuggers? For instance in Common Lisp (continue) invokes the current continue restart, but of course only if there is such a restart. If there is no continue restart (continue) doesn't unwind the stack and simply returns nil. (You'd have to know what a restart is to understand that paragraph, but the "what other languages/debuggers do" is a weak argument anyway.) Helmut From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 04:03:31 2011 Received: (at 9463) by debbugs.gnu.org; 9 Sep 2011 08:03:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1w3f-0002NR-7l for submit@debbugs.gnu.org; Fri, 09 Sep 2011 04:03:31 -0400 Received: from mtaout22.012.net.il ([80.179.55.172]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1w3e-0002NI-75 for 9463@debbugs.gnu.org; Fri, 09 Sep 2011 04:03:30 -0400 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0LR800B00WRVYC00@a-mtaout22.012.net.il> for 9463@debbugs.gnu.org; Fri, 09 Sep 2011 10:59:26 +0300 (IDT) Received: from HOME-C4E4A596F7 ([77.126.9.62]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LR800B8IWV1BKA0@a-mtaout22.012.net.il>; Fri, 09 Sep 2011 10:59:26 +0300 (IDT) Date: Fri, 09 Sep 2011 10:59:31 +0300 From: Eli Zaretskii Subject: Re: bug#9463: 24.0.50; Errors should not be continuable In-reply-to: X-012-Sender: halo1@inter.net.il To: Helmut Eller Message-id: <83lity5eos.fsf@gnu.org> References: <83vct25gxy.fsf@gnu.org> X-Spam-Score: -2.1 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: Eli Zaretskii List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.1 (--) > From: Helmut Eller > Date: Fri, 09 Sep 2011 09:36:59 +0200 > > > I agree with Stefan. The current operation of `c' is consistent with > > what other debuggers do in this situation. For example, when GDB > > catches a fatal signal, typing `c' will simply let the program > > continue with the signal, which may mean it will crash. > > What's the point of being compatible with GDB but not with previous > versions of the Elisp debugger or for that matter with other Lisp > debuggers? At least some users expect the current behavior, I guess. (I don't use CL.) From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 04:27:14 2011 Received: (at submit) by debbugs.gnu.org; 9 Sep 2011 08:27:14 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1wQb-0003aD-OU for submit@debbugs.gnu.org; Fri, 09 Sep 2011 04:27:14 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R1wQX-0003a3-8I for submit@debbugs.gnu.org; Fri, 09 Sep 2011 04:27:11 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1wMb-00046O-Ch for submit@debbugs.gnu.org; Fri, 09 Sep 2011 04:23:06 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:56771) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1wMb-00046K-BG for submit@debbugs.gnu.org; Fri, 09 Sep 2011 04:23:05 -0400 Received: from eggs.gnu.org ([140.186.70.92]:54224) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1wMa-0005UO-BF for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 04:23:05 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R1wMY-000463-U1 for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 04:23:04 -0400 Received: from lo.gmane.org ([80.91.229.12]:34382) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R1wMY-00045v-P3 for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 04:23:02 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R1wMV-0006QN-JI for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 10:22:59 +0200 Received: from dial-176163.pool.broadband44.net ([212.46.176.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 10:22:59 +0200 Received: from eller.helmut by dial-176163.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 10:22:59 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Fri, 09 Sep 2011 10:22:46 +0200 Lines: 19 Message-ID: References: <83vct25gxy.fsf@gnu.org> <83lity5eos.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dial-176163.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:BTgjggUNDbgROZ2Dvpp8X6HlGH4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.5 (-----) * Eli Zaretskii [2011-09-09 07:59] writes: >> From: Helmut Eller >> Date: Fri, 09 Sep 2011 09:36:59 +0200 >> >> > I agree with Stefan. The current operation of `c' is consistent with >> > what other debuggers do in this situation. For example, when GDB >> > catches a fatal signal, typing `c' will simply let the program >> > continue with the signal, which may mean it will crash. >> >> What's the point of being compatible with GDB but not with previous >> versions of the Elisp debugger or for that matter with other Lisp >> debuggers? > > At least some users expect the current behavior, I guess. Well, agreed. Ignorance is bliss. Helmut From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 10:11:28 2011 Received: (at 9463) by debbugs.gnu.org; 9 Sep 2011 14:11:28 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R21nj-0001qs-Vl for submit@debbugs.gnu.org; Fri, 09 Sep 2011 10:11:28 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.181] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R21ng-0001qj-Ct for 9463@debbugs.gnu.org; Fri, 09 Sep 2011 10:11:25 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFALUcak64rwMJ/2dsb2JhbABBoVGGPXmBUgEBBAFWIwULCzQSFBgNJIgJt26GbgSgLYRB X-IronPort-AV: E=Sophos;i="4.68,356,1312171200"; d="scan'208";a="135326727" Received: from 184-175-3-9.dsl.teksavvy.com (HELO pastel.home) ([184.175.3.9]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 09 Sep 2011 10:07:16 -0400 Received: by pastel.home (Postfix, from userid 20848) id E76D74E039; Fri, 9 Sep 2011 10:07:10 -0400 (EDT) From: Stefan Monnier To: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable In-Reply-To: (Helmut Eller's message of "Fri, 09 Sep 2011 08:53:02 +0200") Message-ID: References: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Date: Fri, 09 Sep 2011 10:07:10 -0400 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) >>> I think the "do what would have happened if the debugger had not been >>> called" thing should be a different command, like resignal or abort. >> Why? > 1. Why not? The question is "why" and not "why not": the current behavior is the logical result of writing simple and the clean code. Doing something special when the error is "uncontinuable" requires extra code, so it needs to be justified by a good reason. >> When the debugger is called in a non-error case, the "c" does just >> that "do whatever would have happened if the debug call had no taken place". > 2. it's an incompatible change It's a user-visible change, yes (it doesn't break any code, AFAIK, so it's not what we usually consider as "incompatible"). > 3. it's frustrating when people introduce DWIM-ish features when my > expectations are completely different. There's nothing DWIMish at all about it. >>> c should only continue from truly continuable situations, like >>> breakpoints. >> Again: why? > 4. it's easy to accidentally press c when using d and c multiple times Could you describe a scenario where this would be a problem? > 5. I have already lost valuable information (and time) because of this > too eager stack unwinding. I guess the previous scenario would be the same as this one, but if not, could you describe the scenario where you lost info because of this? > 6. there is nothing wrong with the traditional distinction between > continuable and non-continuable situations. The Elisp debugger does not *catch* signals: it just gets invoked at various points of the execution so you can examine the state. >> PS: The change you seem to dislike is a bug-fix in my opinion, and it has >> fixed a few real problems > It introduced a new bug: r can now be used in every situation. It does extend an old bug to more situations, but it's hardly a new bug. The documentation of debugger-return-value already states very clearly that it's not always useful to use it. >> (e.g. when you enter the debugger from within a minibuffer, you can >> now continue your minibuffer operation, whereas earlier you could >> only abort back to the top-level). > You could do that just as well with a separate resignal command. >From an implementation point of view, at least, calling it "resignal" would be incorrect. All in all, I think what you're asking is for the debugger to be informed of the situation in which it is invoked (e.g. because of a signal, or because of an explicit call, when entering a function, when exiting a function, ...) so that commands like `r' can tell whether they'll be useful and so that we can provide a new command "continue only if this was not a signal" that would behave somewhat like the old "continue" (tho more cleanly since it would burp right away instead of doing the previous dance of first continuing, then having the C-level code figure out that you're trying to continue after a signal and hence re-enter the debugger with a new error). Stefan From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 12:42:37 2011 Received: (at submit) by debbugs.gnu.org; 9 Sep 2011 16:42:37 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R24A0-0003gq-U6 for submit@debbugs.gnu.org; Fri, 09 Sep 2011 12:42:37 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R249t-0003gd-Hl for submit@debbugs.gnu.org; Fri, 09 Sep 2011 12:42:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R245v-0006rd-8e for submit@debbugs.gnu.org; Fri, 09 Sep 2011 12:38:24 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:50969) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R245v-0006rZ-7E for submit@debbugs.gnu.org; Fri, 09 Sep 2011 12:38:23 -0400 Received: from eggs.gnu.org ([140.186.70.92]:50466) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R245u-0001f2-22 for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 12:38:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R245s-0006rI-Mj for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 12:38:22 -0400 Received: from lo.gmane.org ([80.91.229.12]:54845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R245s-0006rE-Ba for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 12:38:20 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R245q-0007mW-Ld for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 18:38:18 +0200 Received: from dial-176163.pool.broadband44.net ([212.46.176.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 18:38:18 +0200 Received: from eller.helmut by dial-176163.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 09 Sep 2011 18:38:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Fri, 09 Sep 2011 18:37:56 +0200 Lines: 95 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dial-176163.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:FvAb+DKWrNmG9Tyd33mH0Mu8Llk= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.5 (-----) * Stefan Monnier [2011-09-09 14:07] writes: >>>> I think the "do what would have happened if the debugger had not been >>>> called" thing should be a different command, like resignal or abort. >>> Why? >> 1. Why not? > > The question is "why" and not "why not": the current behavior is the > logical result of writing simple and the clean code. Doing something > special when the error is "uncontinuable" requires extra code, so it > needs to be justified by a good reason. > >>> When the debugger is called in a non-error case, the "c" does just >>> that "do whatever would have happened if the debug call had no taken place". >> 2. it's an incompatible change > > It's a user-visible change, yes (it doesn't break any code, AFAIK, so > it's not what we usually consider as "incompatible"). >> 3. it's frustrating when people introduce DWIM-ish features when my >> expectations are completely different. > > There's nothing DWIMish at all about it. That's in the eye beholder. c shouldn't "do what would have happened if the debugger had not been called" unless I say so. >>>> c should only continue from truly continuable situations, like >>>> breakpoints. >>> Again: why? >> 4. it's easy to accidentally press c when using d and c multiple times > > Could you describe a scenario where this would be a problem? Let's assume we are hunting down some annoying bug. The debugger just popped up and we execute the sequence: d c d c c c c. The last 4 c are needed for a loop that has a call to debug. Now we are at a moderately interesting place, lets continue: d c. The last c hits an error but we are in a hurry and don't see it. Pressing c again suddenly brings us back to top-level. Duh! The stack is gone. >> 5. I have already lost valuable information (and time) because of this >> too eager stack unwinding. > > I guess the previous scenario would be the same as this one, but if not, > could you describe the scenario where you lost info because of this? I load some data from the network into a temporary buffer for parsing. The parser has a bug and invokes the debugger. Pressing c unwinds the stack and kills the temporary buffer. The input from the network is lost. >> 6. there is nothing wrong with the traditional distinction between >> continuable and non-continuable situations. > > The Elisp debugger does not *catch* signals: it just gets invoked at > various points of the execution so you can examine the state. >>> PS: The change you seem to dislike is a bug-fix in my opinion, and it has >>> fixed a few real problems >> It introduced a new bug: r can now be used in every situation. > > It does extend an old bug to more situations, but it's hardly > a new bug. Interesting way to put it. > The documentation of debugger-return-value already states > very clearly that it's not always useful to use it. >>> (e.g. when you enter the debugger from within a minibuffer, you can >>> now continue your minibuffer operation, whereas earlier you could >>> only abort back to the top-level). >> You could do that just as well with a separate resignal command. > > From an implementation point of view, at least, calling it "resignal" > would be incorrect. Are we playing with definitions? > > All in all, I think what you're asking is for the debugger to be > informed of the situation in which it is invoked (e.g. because of > a signal, or because of an explicit call, when entering a function, when > exiting a function, ...) so that commands like `r' can tell whether > they'll be useful and so that we can provide a new command "continue > only if this was not a signal" that would behave somewhat like the old > "continue" (tho more cleanly since it would burp right away instead of > doing the previous dance of first continuing, then having the C-level > code figure out that you're trying to continue after a signal and hence > re-enter the debugger with a new error). Specifically, I'm saying that c should not unwind the stack after errors. Helmut From debbugs-submit-bounces@debbugs.gnu.org Fri Sep 09 17:48:33 2011 Received: (at 9463) by debbugs.gnu.org; 9 Sep 2011 21:48:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R28w5-0008DJ-FL for submit@debbugs.gnu.org; Fri, 09 Sep 2011 17:48:33 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R28w3-0008DC-B3 for 9463@debbugs.gnu.org; Fri, 09 Sep 2011 17:48:32 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAIWIak64rwMJ/2dsb2JhbABCoViGPXmBUgEBBAFWIwULCzQSFBgNJIgJuC+GbgSgLYRB X-IronPort-AV: E=Sophos;i="4.68,358,1312171200"; d="scan'208";a="135383650" Received: from 184-175-3-9.dsl.teksavvy.com (HELO pastel.home) ([184.175.3.9]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 09 Sep 2011 17:44:23 -0400 Received: by pastel.home (Postfix, from userid 20848) id BDE5B589E5; Fri, 9 Sep 2011 17:44:22 -0400 (EDT) From: Stefan Monnier To: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Message-ID: References: Date: Fri, 09 Sep 2011 17:44:22 -0400 In-Reply-To: (Helmut Eller's message of "Fri, 09 Sep 2011 18:37:56 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) > > There's nothing DWIMish at all about it. > That's in the eye beholder. Not at all: the code is proof that there is nothing DWIMish about it. I know DWIM when I see it, and I assure you there's no such thing here. > Let's assume we are hunting down some annoying bug. The debugger just > popped up and we execute the sequence: d c d c c c c. The last 4 c are > needed for a loop that has a call to debug. Now we are at a moderately > interesting place, lets continue: d c. The last c hits an error but we > are in a hurry and don't see it. Pressing c again suddenly brings us > back to top-level. Duh! The stack is gone. But the same happens in many other circumstances where no error shows up: the loop goes around N times, and you hit "c" just one extra time and poof the loop ends, returns to the caller who deletes the temp buffer and your network data is gone. I understand you liked the old behavior because it ended up providing a heuristic way to prevent you from stepping too far, and in your experience this worked well. >> All in all, I think what you're asking is for the debugger to be >> informed of the situation in which it is invoked (e.g. because of >> a signal, or because of an explicit call, when entering a function, when >> exiting a function, ...) so that commands like `r' can tell whether >> they'll be useful and so that we can provide a new command "continue >> only if this was not a signal" that would behave somewhat like the old >> "continue" (tho more cleanly since it would burp right away instead of >> doing the previous dance of first continuing, then having the C-level >> code figure out that you're trying to continue after a signal and hence >> re-enter the debugger with a new error). > Specifically, I'm saying that c should not unwind the stack after > errors. I understand that's what you want. The fixes I installed in the C side were done to make it possible for "c" to continue after an error, which is a very useful behavior in several cases. So I'm definitely not going to revert this change. What I can offer is to provide more flexibility so you could for instance rebind "c" to some command that simulates the behavior you used to get with "c". We could also consider changing "c" so it asks for confirmation before continuing from an error. But for any of that, we first have to change the code so that "c" can know whether we were called because of an error or not: currently "c" doesn't known that (and it didn't know that either in earlier Emacsen). Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Sep 10 14:31:54 2011 Received: (at submit) by debbugs.gnu.org; 10 Sep 2011 18:31:54 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2SLJ-0007oD-Sw for submit@debbugs.gnu.org; Sat, 10 Sep 2011 14:31:54 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R2SLH-0007o5-7Z for submit@debbugs.gnu.org; Sat, 10 Sep 2011 14:31:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R2SHC-0005Js-UH for submit@debbugs.gnu.org; Sat, 10 Sep 2011 14:27:39 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-4.7 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:53804) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2SHC-0005Jl-SZ for submit@debbugs.gnu.org; Sat, 10 Sep 2011 14:27:38 -0400 Received: from eggs.gnu.org ([140.186.70.92]:41203) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2SHB-0003YC-Il for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2011 14:27:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R2SHA-0005JA-Km for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2011 14:27:37 -0400 Received: from lo.gmane.org ([80.91.229.12]:41806) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R2SHA-0005J3-Aj for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2011 14:27:36 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R2SH9-0005Mp-9X for bug-gnu-emacs@gnu.org; Sat, 10 Sep 2011 20:27:35 +0200 Received: from dial-176163.pool.broadband44.net ([212.46.176.163]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Sep 2011 20:27:35 +0200 Received: from eller.helmut by dial-176163.pool.broadband44.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 10 Sep 2011 20:27:35 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Sat, 10 Sep 2011 20:27:22 +0200 Lines: 96 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: dial-176163.pool.broadband44.net User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:WaESvysHGwh+7xoFHg+Qh5Fy0wE= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.5 (-----) * Stefan Monnier [2011-09-09 21:44] writes: >> Specifically, I'm saying that c should not unwind the stack after >> errors. > > I understand that's what you want. The fixes I installed in the C side > were done to make it possible for "c" to continue after an error, which > is a very useful behavior in several cases. So I'm definitely not going > to revert this change. > > What I can offer is to provide more flexibility so you could for > instance rebind "c" to some command that simulates the behavior you used > to get with "c". We could also consider changing "c" so it asks for > confirmation before continuing from an error. > > But for any of that, we first have to change the code so that "c" can > know whether we were called because of an error or not: currently "c" > doesn't known that (and it didn't know that either in earlier Emacsen). The patch below is what I think that the debugger should do. Incidentally, C-M-c does pretty much the same as what c does currently. So, no new command to get the current behavior would be needed. === modified file 'lisp/emacs-lisp/debug.el' --- lisp/emacs-lisp/debug.el 2011-08-22 21:16:46 +0000 +++ lisp/emacs-lisp/debug.el 2011-09-10 18:23:13 +0000 @@ -98,6 +98,9 @@ (defvar inhibit-trace) ;Not yet implemented. +(defvar debugger-args nil + "Arguments passed to `debug'.") + ;;;###autoload (setq debugger 'debug) ;;;###autoload @@ -419,15 +422,27 @@ (message "Proceeding, will debug on next eval or call.") (exit-recursive-edit)) +(defun debugger-continuable-p () + "Can we reasonably continue from the current situation?" + (and debugger-may-continue + (not (eq (car debugger-args) + 'error)))) + (defun debugger-continue () "Continue, evaluating this expression without stopping." (interactive) - (unless debugger-may-continue - (error "Cannot continue")) - (message "Continuing.") + (cond ((debugger-condition-continuable-p) + (message "Continuing.") + (debugger-exit-recursive-edit)) + (t + (message "Cannot continue") + (ding)))) + +(defun debugger-exit-recursive-edit () + ;; Exit but first check if we've flagged some frame for + ;; debug-on-exit, in which case we'll probably come back to the + ;; debugger soon. (save-excursion - ;; Check to see if we've flagged some frame for debug-on-exit, in which - ;; case we'll probably come back to the debugger soon. (goto-char (point-min)) (if (re-search-forward "^\\* " nil t) (setq debugger-will-be-back t))) @@ -438,16 +453,14 @@ This is only useful when the value returned from the debugger will be used, such as in a debug on exit from a frame." (interactive "XReturn value (evaluated): ") - (setq debugger-value val) - (princ "Returning " t) - (prin1 debugger-value) - (save-excursion - ;; Check to see if we've flagged some frame for debug-on-exit, in which - ;; case we'll probably come back to the debugger soon. - (goto-char (point-min)) - (if (re-search-forward "^\\* " nil t) - (setq debugger-will-be-back t))) - (exit-recursive-edit)) + (cond ((debugger-condition-continuable-p) + (setq debugger-value val) + (princ "Returning " t) + (prin1 debugger-value) + (debugger-exit-recursive-edit)) + (t + (message "Cannot return") + (ding)))) (defun debugger-jump () "Continue to exit from this frame, with all debug-on-entry suspended." From debbugs-submit-bounces@debbugs.gnu.org Mon Sep 19 17:22:11 2011 Received: (at 9463) by debbugs.gnu.org; 19 Sep 2011 21:22:11 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5lI0-00044z-PE for submit@debbugs.gnu.org; Mon, 19 Sep 2011 17:22:10 -0400 Received: from ironport2-out.teksavvy.com ([206.248.154.183] helo=ironport2-out.pppoe.ca) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5lHx-00044r-57 for 9463@debbugs.gnu.org; Mon, 19 Sep 2011 17:22:06 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMWwd05FpZ7x/2dsb2JhbABCp0B4gVMBAQQBViMFCws0EhQYDSSICrUwhngEoE6ERA X-IronPort-AV: E=Sophos;i="4.68,407,1312171200"; d="scan'208";a="137178511" Received: from 69-165-158-241.dsl.teksavvy.com (HELO pastel.home) ([69.165.158.241]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 19 Sep 2011 17:17:01 -0400 Received: by pastel.home (Postfix, from userid 20848) id DA0C559218; Mon, 19 Sep 2011 17:17:00 -0400 (EDT) From: Stefan Monnier To: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Message-ID: References: Date: Mon, 19 Sep 2011 17:17:00 -0400 In-Reply-To: (Helmut Eller's message of "Sat, 10 Sep 2011 20:27:22 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) > Incidentally, C-M-c does pretty much the same as what c does currently. It does something similar but not identical and hence re-introduces some of the problems that the change you don't like aimed to solve. It's important to have a "c" that can "keep going (as much as possible) as if nothing happened". As you've shown, you can actually get your old behavior with something like (defadvice debugger-continue (before dont-continue-after-error activate) (if (eq (car debugger-args) 'error) (error "Can't continue from an error"))) > So, no new command to get the current behavior would be needed. Indeed. I've installed a change to catch the most common cases where debugger-return-value doesn't make sense. Stefan From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 20 02:54:38 2011 Received: (at submit) by debbugs.gnu.org; 20 Sep 2011 06:54:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5uE1-00010O-Nv for submit@debbugs.gnu.org; Tue, 20 Sep 2011 02:54:38 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R5uDv-00010B-Nz for submit@debbugs.gnu.org; Tue, 20 Sep 2011 02:54:33 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5u8z-0001OJ-D3 for submit@debbugs.gnu.org; Tue, 20 Sep 2011 02:49:26 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RCVD_NUMERIC_HELO, RP_MATCHES_RCVD, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:46695) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5u8z-0001OF-AG for submit@debbugs.gnu.org; Tue, 20 Sep 2011 02:49:25 -0400 Received: from eggs.gnu.org ([140.186.70.92]:37596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5u8x-0000Zk-Vm for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 02:49:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R5u8x-0001Nl-44 for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 02:49:23 -0400 Received: from lo.gmane.org ([80.91.229.12]:43967) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R5u8w-0001Nf-P6 for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 02:49:23 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R5u8v-0004kI-Kf for bug-gnu-emacs@gnu.org; Tue, 20 Sep 2011 08:49:21 +0200 Received: from 212.46.173.155 ([212.46.173.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Sep 2011 08:49:21 +0200 Received: from eller.helmut by 212.46.173.155 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 20 Sep 2011 08:49:21 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Tue, 20 Sep 2011 08:49:10 +0200 Lines: 15 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 212.46.173.155 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:QYiPFxNaMQ3u1+4S9bllxZq77y4= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.5 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.5 (----) * Stefan Monnier [2011-09-19 21:17] writes: >> Incidentally, C-M-c does pretty much the same as what c does currently. > > It does something similar but not identical and hence re-introduces some > of the problems that the change you don't like aimed to solve. And what exactly is the difference between C-M-c and c? > It's important to have a "c" that can "keep going (as much as possible) > as if nothing happened". And why was this not important in previous releases? Helmut From debbugs-submit-bounces@debbugs.gnu.org Tue Sep 20 17:53:18 2011 Received: (at 9463) by debbugs.gnu.org; 20 Sep 2011 21:53:18 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R68Fi-0002n1-NR for submit@debbugs.gnu.org; Tue, 20 Sep 2011 17:53:18 -0400 Received: from pruche.dit.umontreal.ca ([132.204.246.22]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R68Fh-0002mu-Ui for 9463@debbugs.gnu.org; Tue, 20 Sep 2011 17:53:18 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p8KLr35v031338; Tue, 20 Sep 2011 17:53:03 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id 8D80AB4170; Tue, 20 Sep 2011 17:53:04 -0400 (EDT) From: Stefan Monnier To: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Message-ID: References: Date: Tue, 20 Sep 2011 17:53:04 -0400 In-Reply-To: (Helmut Eller's message of "Tue, 20 Sep 2011 08:49:10 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3986=0 X-NAI-Spam-Version: 2.2.0.9286 : core <3986> : streams <683534> : uri <964616> X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) >>> Incidentally, C-M-c does pretty much the same as what c does currently. >> It does something similar but not identical and hence re-introduces some >> of the problems that the change you don't like aimed to solve. > And what exactly is the difference between C-M-c and c? C-M-c does a (throw 'exit), so in the case where we've caught a signal, it prevents the condition-case catchers from doing their job. >> It's important to have a "c" that can "keep going (as much as possible) >> as if nothing happened". > And why was this not important in previous releases? That's not a very constructive line of argument, I'm afraid. Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 21 04:06:03 2011 Received: (at submit) by debbugs.gnu.org; 21 Sep 2011 08:06:03 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R6Hog-0001cc-NH for submit@debbugs.gnu.org; Wed, 21 Sep 2011 04:06:03 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R6Hod-0001cE-VV for submit@debbugs.gnu.org; Wed, 21 Sep 2011 04:06:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6HoP-0001C7-4i for submit@debbugs.gnu.org; Wed, 21 Sep 2011 04:05:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RCVD_NUMERIC_HELO, RP_MATCHES_RCVD, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:37929) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6HoP-0001C3-3G for submit@debbugs.gnu.org; Wed, 21 Sep 2011 04:05:45 -0400 Received: from eggs.gnu.org ([140.186.70.92]:51641) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6HoJ-0005Pp-KA for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 04:05:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6HoD-0001Am-Q3 for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 04:05:39 -0400 Received: from lo.gmane.org ([80.91.229.12]:46892) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6HoD-0001Aa-4p for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 04:05:33 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R6HoB-0006wq-J4 for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 10:05:31 +0200 Received: from 212.46.173.155 ([212.46.173.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 10:05:31 +0200 Received: from eller.helmut by 212.46.173.155 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 10:05:31 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Wed, 21 Sep 2011 10:05:19 +0200 Lines: 48 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 212.46.173.155 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:nQvTNT2smZfsrpH7kLPW8eF1iWA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.5 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.5 (----) * Stefan Monnier [2011-09-20 21:53] writes: >>>> Incidentally, C-M-c does pretty much the same as what c does currently. >>> It does something similar but not identical and hence re-introduces some >>> of the problems that the change you don't like aimed to solve. >> And what exactly is the difference between C-M-c and c? > > C-M-c does a (throw 'exit), so in the case where we've caught a signal, > it prevents the condition-case catchers from doing their job. As matter of fact, c calls exit-recursive-edit (= C-M-c). So (throw 'exit) can't be the difference. Also the debugger is usually not invoked if there is a matching condition handler, e.g. (let ((debug-on-error t)) (condition-case c (error "e") (error c))) doesn't invoke the debugger. Let's call this situation 0. We can have a matching condition handler (only) in these situations: 1. debug-on-error=t and the handler is flagged with debug, e.g.: (let ((debug-on-error t)) (condition-case c (error "e") ((debug error) c))) 2. debug-on-signal=t 3. debug-on-quit=t In 1, 2, and 3 it might be a good thing to continue to unwind the stack. But the situation I'm interested is like this: (let ((debug-on-error t)) (error "foo")) It is different from 0 and 1 and never has a matching condition handler. >>> It's important to have a "c" that can "keep going (as much as possible) >>> as if nothing happened". >> And why was this not important in previous releases? > > That's not a very constructive line of argument, I'm afraid. c now destroys information (backtrace, temporary buffers) in more situations than in previous releases. I hope that we agree on this. You claim that this is "important". You neither explain why it is important nor why not destroying information was a problem previously. Helmut From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 21 15:10:15 2011 Received: (at 9463) by debbugs.gnu.org; 21 Sep 2011 19:10:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R6SBT-0001Yt-9T for submit@debbugs.gnu.org; Wed, 21 Sep 2011 15:10:15 -0400 Received: from chene.dit.umontreal.ca ([132.204.246.20]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R6SBQ-0001Yi-6K for 9463@debbugs.gnu.org; Wed, 21 Sep 2011 15:10:13 -0400 Received: from faina.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id p8LJ9pSH023068; Wed, 21 Sep 2011 15:09:52 -0400 Received: by faina.iro.umontreal.ca (Postfix, from userid 20848) id BE836B41D0; Wed, 21 Sep 2011 15:09:50 -0400 (EDT) From: Stefan Monnier To: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Message-ID: References: Date: Wed, 21 Sep 2011 15:09:50 -0400 In-Reply-To: (Helmut Eller's message of "Wed, 21 Sep 2011 10:05:19 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV3987=0 X-NAI-Spam-Version: 2.2.0.9286 : core <3987> : streams <683844> : uri <965366> X-Spam-Score: -2.0 (--) X-Debbugs-Envelope-To: 9463 Cc: 9463@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.0 (--) >>>>> Incidentally, C-M-c does pretty much the same as what c does currently. >>>> It does something similar but not identical and hence re-introduces some >>>> of the problems that the change you don't like aimed to solve. >>> And what exactly is the difference between C-M-c and c? >> C-M-c does a (throw 'exit), so in the case where we've caught a signal, >> it prevents the condition-case catchers from doing their job. > As matter of fact, c calls exit-recursive-edit (= C-M-c). > So (throw 'exit) can't be the difference. Ah, yes, indeed, I forgot about that part. So yes, C-M-c behaves very similarly (other than details like keeping the window displayed if there's a upper-level frame marked for debug-on-exit). > c now destroys information (backtrace, temporary buffers) in more > situations than in previous releases. I hope that we agree on this. `c' always destroys information when it works. And since it now works in more cases, it indeed destroys information in more situations. I think it's a feature. > You claim that this is "important". You neither explain why it is > important nor why not destroying information was a problem previously. I already explained. You just disagree that this is important, and you instead think it's more important to use the "stop at error" as a heuristic to prevent you from stepping too far. My experience is different, so we disagree. Have you tried the defadvice I suggested? Stefan From debbugs-submit-bounces@debbugs.gnu.org Wed Sep 21 15:54:26 2011 Received: (at submit) by debbugs.gnu.org; 21 Sep 2011 19:54:26 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R6SsE-0003OV-Ai for submit@debbugs.gnu.org; Wed, 21 Sep 2011 15:54:26 -0400 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1R6SsC-0003OO-ID for submit@debbugs.gnu.org; Wed, 21 Sep 2011 15:54:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6Sru-0002ky-F6 for submit@debbugs.gnu.org; Wed, 21 Sep 2011 15:54:07 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_MED, RCVD_NUMERIC_HELO, RP_MATCHES_RCVD, T_TO_NO_BRKTS_FREEMAIL autolearn=unavailable version=3.3.1 Received: from lists.gnu.org ([140.186.70.17]:54005) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6Sru-0002ku-De for submit@debbugs.gnu.org; Wed, 21 Sep 2011 15:54:06 -0400 Received: from eggs.gnu.org ([140.186.70.92]:43238) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6Srt-0001ad-D2 for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 15:54:06 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6Srs-0002kO-JO for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 15:54:05 -0400 Received: from lo.gmane.org ([80.91.229.12]:43820) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6Srs-0002kE-Cj for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 15:54:04 -0400 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1R6Srq-0000hd-RT for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 21:54:02 +0200 Received: from 212.46.173.155 ([212.46.173.155]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 21:54:02 +0200 Received: from eller.helmut by 212.46.173.155 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 21 Sep 2011 21:54:02 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: bug-gnu-emacs@gnu.org From: Helmut Eller Subject: Re: bug#9463: 24.0.50; Errors should not be continuable Date: Wed, 21 Sep 2011 21:53:51 +0200 Lines: 15 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 212.46.173.155 User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) Cancel-Lock: sha1:mqWYyoua+khqm/vWZuaQnBFxuxg= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -4.5 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.5 (----) * Stefan Monnier [2011-09-21 19:09] writes: >> You claim that this is "important". You neither explain why it is >> important nor why not destroying information was a problem previously. > > I already explained. You just disagree that this is important, and you > instead think it's more important to use the "stop at error" as > a heuristic to prevent you from stepping too far. My experience > is different, so we disagree. > Have you tried the defadvice I suggested? No, because I was hoping that reporting a bug is not a waste of time. Now I know better. Helmut From debbugs-submit-bounces@debbugs.gnu.org Fri Oct 07 16:03:17 2011 Received: (at control) by debbugs.gnu.org; 7 Oct 2011 20:03:17 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RCGdY-0002IY-S6 for submit@debbugs.gnu.org; Fri, 07 Oct 2011 16:03:17 -0400 Received: from fencepost.gnu.org ([140.186.70.10]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RCGdX-0002IR-BH for control@debbugs.gnu.org; Fri, 07 Oct 2011 16:03:16 -0400 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1RCGdH-000174-0P for control@debbugs.gnu.org; Fri, 07 Oct 2011 16:02:59 -0400 Date: Fri, 07 Oct 2011 16:02:59 -0400 Message-Id: Subject: control message for bug 9463 To: X-Mailer: mail (GNU Mailutils 2.1) From: Glenn Morris X-Spam-Score: -6.4 (------) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -6.4 (------) tag 9463 notabug wontfix From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 21 21:22:40 2012 Received: (at 9463-done) by debbugs.gnu.org; 22 Feb 2012 02:22:40 +0000 Received: from localhost ([127.0.0.1]:49616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S01qq-000806-Fu for submit@debbugs.gnu.org; Tue, 21 Feb 2012 21:22:40 -0500 Received: from fencepost.gnu.org ([140.186.70.10]:55491 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1S01qo-0007zz-Lf for 9463-done@debbugs.gnu.org; Tue, 21 Feb 2012 21:22:39 -0500 Received: from rgm by fencepost.gnu.org with local (Exim 4.71) (envelope-from ) id 1S01oY-00063c-CV; Tue, 21 Feb 2012 21:20:18 -0500 From: Glenn Morris To: 9463-done@debbugs.gnu.org Subject: Re: bug#9463: 24.0.50; Errors should not be continuable References: X-Spook: morse George W. Bush spy Freeh virus clones Albania X-Ran: cyf#T,R>U3Ah(?'ddp5{_n1}Smj3d]2V#B;#G-|?>Ge{-7}449uI-ua[D*\Ua(X`q<5& (Helmut Eller's message of "Wed, 21 Sep 2011 21:53:51 +0200") Message-ID: User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -4.2 (----) X-Debbugs-Envelope-To: 9463-done X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -4.2 (----) Thanks for the report, but as was explained the behaviour is not going to change, so I am closing this as "wontfix". From unknown Sat Aug 16 15:58:24 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 21 Mar 2012 11:24:12 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator