GNU bug report logs - #9463
24.0.50; Errors should not be continuable

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9463 in the body.
You can then email your comments to 9463 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50; Errors should not be continuable
Date: Thu, 08 Sep 2011 14:01:31 +0200

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''

Message #8 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Thu, 08 Sep 2011 09:31:40 -0400

> 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

Message #11 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Thu, 08 Sep 2011 20:13:05 +0200

* 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

Message #14 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Thu, 08 Sep 2011 22:23:09 -0400

>>> 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).

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 08:53:02 +0200

* 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

Message #20 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 9463 <at> debbugs.gnu.org, eller.helmut <at> gmail.com
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 10:10:49 +0300

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Thu, 08 Sep 2011 22:23:09 -0400
> Cc: 9463 <at> 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.

Message #23 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 09:36:59 +0200

* Eli Zaretskii [2011-09-09 07:10] writes:

>> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
>> Date: Thu, 08 Sep 2011 22:23:09 -0400
>> Cc: 9463 <at> 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

Message #26 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 10:59:31 +0300

> From: Helmut Eller <eller.helmut <at> gmail.com>
> 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.)

Message #29 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 10:22:46 +0200

* Eli Zaretskii [2011-09-09 07:59] writes:

>> From: Helmut Eller <eller.helmut <at> gmail.com>
>> 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

Message #32 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 10:07:10 -0400

>>> 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

Message #35 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 18:37:56 +0200

* 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

Message #38 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Fri, 09 Sep 2011 17:44:22 -0400

> > 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

Message #41 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Sat, 10 Sep 2011 20:27:22 +0200

* 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."

Message #44 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Mon, 19 Sep 2011 17:17:00 -0400

> 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

Message #47 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Tue, 20 Sep 2011 08:49:10 +0200

* 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

Message #50 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Tue, 20 Sep 2011 17:53:04 -0400

>>> 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

Message #53 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Wed, 21 Sep 2011 10:05:19 +0200

* 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

Message #56 received at 9463 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 9463 <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Wed, 21 Sep 2011 15:09:50 -0400

>>>>> 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

Message #59 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Helmut Eller <eller.helmut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Wed, 21 Sep 2011 21:53:51 +0200

* 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

Message #66 received at 9463-done <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 9463-done <at> debbugs.gnu.org
Subject: Re: bug#9463: 24.0.50; Errors should not be continuable
Date: Tue, 21 Feb 2012 21:20:18 -0500

Thanks for the report, but as was explained the behaviour is not going
to change, so I am closing this as "wontfix".

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.