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: Fri, 09 Sep 2011 18:37:56 +0200 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1315586346 13817 80.91.229.12 (9 Sep 2011 16:39:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 9 Sep 2011 16:39:06 +0000 (UTC) To: 9463@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 09 18:39:02 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 1R246X-00086Q-KV for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2011 18:39:01 +0200 Original-Received: from localhost ([::1]:50810 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R246X-0001hK-8N for geb-bug-gnu-emacs@m.gmane.org; Fri, 09 Sep 2011 12:39:01 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:50552) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R246U-0001gK-KA for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 12:38:59 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R246T-0006uM-JN for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 12:38:58 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:35252) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R246T-0006uI-Ho for bug-gnu-emacs@gnu.org; Fri, 09 Sep 2011 12:38:57 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.69) (envelope-from ) id 1R24AQ-0003hS-Cd; Fri, 09 Sep 2011 12:43:02 -0400 X-Loop: help-debbugs@gnu.org In-Reply-To: Resent-From: Helmut Eller 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 16:43: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: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.131558655714191 (code B ref -1); Fri, 09 Sep 2011 16:43:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 9 Sep 2011 16:42:37 +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 1R24A0-0003gq-U6 for submit@debbugs.gnu.org; Fri, 09 Sep 2011 12:42:37 -0400 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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 Original-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/ Original-Lines: 95 Original-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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list Resent-Date: Fri, 09 Sep 2011 12:43:02 -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:50769 Archived-At: * 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