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

[Drew Adams]

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

>From a user point of view, `c' continues debugging (without digging deeper
like `d' does), and `q' quits debugging. I'm speaking only from a user point
of view. What the implementation considers "leaving", "aborting",
"continuing", etc. I don't really care about.

>From a user point of view, I want to continue debugging when I use `c'
(unless I'm back to the top level), and I want to quit debugging when I use
`q'. `c' should keep the debugger displayed (unless it is somehow smart
enough to know that I'm done with it), and `q' should stop displaying it, if
possible.

If it is too complex to know when to remove the debugger, then it should
remain displayed - the user can always get rid of the frame himself, if
necessary. The Emacs 20 behavior was an improvement over the current
behavior: no flickering/flashing, no iconifying, no premature exiting of
debugging - you can add that to the Antinews on my behalf ;-).

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

    That depends on the circumstance.  See below.

Yes, I too mentioned that at the top level `c' effectively takes you out.
Nevertheless, if it is too complex to distinguish this case, then just let
users use `q' to signal that they are finished.

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

I suggested making the frame invisible (instead of deleting or iconifying
it) when the buffer is left definitively - that should keep the
size&positition info. Have you tried that? After all, that's what we're
after here: I want to stop displaying the frame, and you want to retain its
size&position info. Just set the visible frame parameter to nil, and leave
the size and position info as is.

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

Right; good.

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

Is there a typo there somewhere? You suggest I use mostly debug-on-error and
you use mostly debug-on-error (and others) - but you suggest there is a
difference between us on this.

I use debug-on-entry mostly (easy to cancel; no code to modify). I also have
debug-on-error set to non-nil, but mostly I'm concerned about
debug-on-entry. And I also use explicit calls to (debug). I see these three
(debug-on-entry, debug-on-error, just debug) as the same: they put you into
the debugger, then you decide how long you want to stay there.

I've never used edebug. Actually, I tried it a couple times, but had bad
luck with it (I don't remember the details).

    > 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 guessed that might be the case. I suggested maybe testing that the buffer
is empty, but I'm not sure when you could do that, if the code in question
has already exited.

Again, if `c' can't figure out whether the user is really done (top level),
then users can just use `q' to signal that they are done, always. That's not
a big problem. The problem of `c' not continuing to display the debugger at
levels below top level is a big problem.

    I'll send a patch later.

Great!

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

You might want to check how it was done in Emacs 20. Things seemed to DTRT
then, IMO.