From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.bugs Subject: bug#9463: 24.0.50; Errors should not be continuable Date: Fri, 09 Sep 2011 10:07:10 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1315577290 10266 80.91.229.12 (9 Sep 2011 14:08:10 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2011 14:08:10 +0000 (UTC) Cc: 9463@debbugs.gnu.org To: Helmut Eller Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 09 16:08:06 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 1R21kS-0003Vs-Lu for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2011 16:08:04 +0200 Original-Received: from localhost ([::1]:34895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R21kS-0000TW-5O for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2011 10:08:04 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:54652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R21kP-0000TR-2U for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 10:08:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R21kN-0006Te-CN for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 10:08:00 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:46456) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R21kN-0006TY-7Z for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 10:07:59 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R21oJ-0001rj-7i; Fri, 09 Sep 2011 10:12:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: debbugs-submit-bounces@debbugs.gnu.org Resent-To: owner@debbugs.gnu.org Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2011 14:12:02 +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: Original-Received: via spool by 9463-submit@debbugs.gnu.org id=B9463.13155774887125 (code B ref 9463); Fri, 09 Sep 2011 14:12:02 +0000 Original-Received: (at 9463) by debbugs.gnu.org; 9 Sep 2011 14:11:28 +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 1R21nj-0001qs-Vl for submit@debbugs.gnu.org; Fri, 09 Sep 2011 10:11:28 -0400 Original-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" Original-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 Original-Received: by pastel.home (Postfix, from userid 20848) id E76D74E039; Fri, 9 Sep 2011 10:07:10 -0400 (EDT) In-Reply-To: (Helmut Eller's message of "Fri, 09 Sep 2011 08:53:02 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 09 Sep 2011 10:12:03 -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:50764 Archived-At: >>> 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