Re: debugger with pop-up-frames non-nil: keeps creating new frames

[Stefan Monnier]

>     I'm saying that in the case of `q' or `c', I don't want the keep
>     displaying the frame, instead I want it iconified.

> In the case of `c', I definitely want to keep displaying the debugger. Why
> would you want it to disappear? Using `c' doesn't mean you're done with the
> debugger. I can always use `q' when I'm done with the debugger.

`q' doesn't just leave the debugger, it also aborts the current execution,
whereas `c' continues it (without necessarily setting things up to re-enter
the debugger in the future).

>     Because `q' and `c' both really leave the debugger so you don't want
>     to keep an empty *Backtrace* buffer/window/frame staring at you.

> `c' does not leave the debugger at all. It simply completes evaluation of a
> sexp.

That depends on the circumstance.  See below.

> Again, quitting the debugger should delete the buffer, window and frame (if
> one-window-p) - iconifying serves no purpose. What is wrong with deleting
> the buffer/window/frame?

What's unclear about "losing the size&position info"?

> And `d' and`c' should not be considered to "leave" the debugger at all - the
> debugger buffer/window/frame should continue to be displayed.

With the current code, `d' indeed keeps the backtrace buffer displayed.

> I don't understand this. I use `d' and `c' all the time. I use `c' when I
> don't want to drill down into the eval of a sexp; I just want to see its
> result. But that still leaves me in the middle of a trace, and I continue
> with `d' or `c' to evaluate the next sexp (or I quit with `q', if I'm done).

I think I'm beginning to understand a bit more what you're complaining
about.  IIUC you use debug-on-error extensively, whereas I use edebug for
those situations.  I mostly only use the `debug' debugger via
debug-on-error, debug-on-signal, debug-on-quit, or an explicit call to
(debug).

> Of course, if the sexp to be eval'd with `c' is the only one, then
> evaluation is finished, and you end up with an empty buffer.  That is the
> only case when it would be OK to remove the buffer/window/frame after `c'
> is finished.

Indeed, except it's not easy to distinguish the different cases.  I'll send
a patch later.

>     so the last patch I sent you tries to hide it, but it is the reason
>     why I consider `d' to "leave" the debugger.

> OK. Is that how it worked previously also? `d' caused function `debug' to
> return (exit) at each step?

Yes, it's always worked this way.

>> You're still in the debugger; why delete and re-create the window?

Probably for simple implementation reasons.  And maybe also so that the
code itself is run in an environment unaffected by the debugger.
I.e. without the extra window.


        Stefan