From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.bugs Subject: bug#9463: 24.0.50; Errors should not be continuable Date: Wed, 21 Sep 2011 10:05:19 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1316592421 13852 80.91.229.12 (21 Sep 2011 08:07:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 21 Sep 2011 08:07:01 +0000 (UTC) To: 9463@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 21 10:06:57 2011 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R6HpY-0007UL-Jp for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Sep 2011 10:06:56 +0200 Original-Received: from localhost ([::1]:51289 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6HpY-0005Yn-3c for geb-bug-gnu-emacs@m.gmane.org; Wed, 21 Sep 2011 04:06:56 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:55192) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6HpR-0005Yi-K7 for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 04:06:53 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R6HpQ-0001HE-CU for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 04:06:49 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:41631) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R6HpQ-0001HA-Aw for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 04:06:48 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R6Hpd-0001dv-Ql for bug-gnu-emacs@gnu.org; Wed, 21 Sep 2011 04:07:01 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Helmut Eller Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Sep 2011 08:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 9463 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.13165923636242 (code B ref -1); Wed, 21 Sep 2011 08:07:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 21 Sep 2011 08:06:03 +0000 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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/ Original-Lines: 48 Original-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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Wed, 21 Sep 2011 04:07:01 -0400 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 1) X-Received-From: 140.186.70.43 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.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:51569 Archived-At: * 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