bug#9463: 24.0.50; Errors should not be continuable

[Stefan Monnier <monnier@iro.umontreal.ca>]

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