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

[Stefan Monnier]

>> If I do (setq special-display-regexps '("[ ]?[*][^*]+[*]")), then when I hit
>> `d' in the debugger, the debugger frame iconifies.

>     Doesn't it de-iconify right after (thus flashing)?  That's very odd.

> No; it does not deiconify.

Oh, I think I know what it is: that's because of Richard's new code which
uses just `select-window' instead of `pop-to-buffer' and thus fails to
de-iconify.

> If it did, I would consider that too to be a bug - why would one want the
> debugger frame to first be iconified and then be deiconified each time you
> issue a debugger command?

Yes, it'd also be a bug.  But it'd be fixed by the last patch I sent.

>> I don't understand:
>> - Why bury-buffer iconifies.
>     Because of the case where you hit `q' or `c' or ... rather than `d'.
> I don't understand what you are saying here.

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.

> It iconifies with every command, including `d'. But, aside from `d', why
> should it iconify with `q' or `c'?

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.

> If you hit `q', perhaps iconifying is OK. However, I think quit-window or
> killing the buffer and deleting the window (and frame) would be better than
> iconifying the frame.

Have you read the patches I sent and the corresponding code?  It includes
a comment explaining why.

> Even if iconifying were OK for `q', why do that when you hit `c'? You are
> still using the debugger window/buffer/frame, no?

Sometimes, but usually no.  Or at least I won't get back into the debugger
immediately (contrary to `d').

> Why would you want to bury or iconify the buffer with `c'? It should
> remain displayed, so you can use it.

You can't really use it any more: at that point it's empty (until you
re-enter the debugger).

>     Actually the code is used when we leave the debugger.  It's just that
>     when you use `d' you only leave the debugger temporarily.

> I don't see why you (or the code) would consider `d' to "leave" the
> debugger, even temporarily. In what sense is the user leaving it?

The debugger is entered by calling the function `debug' and is exited when
the `debug' function returns.  The code in question is executed at the end
of `debug' just before exiting.  I.e.  technically, `d' causes Emacs to
leave the debugger while setting up the evaluator to "immediately" re-enter
the debugger.

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

> Even if one considers `d' to "leave" the debugger, that way of "leaving" it
> requires a completely different behavior from quitting it (`q)', IMO.

Agreed, thus my patch.

>     If you look at what happens in a single-frame case, the code
>     deletes/creates a window at each step.
> I don't see why it should do that either.

The why is not really relevant: it's what it does (by wrapping the body of
`debug' within a save-window-excursion).

> You're still in the debugger; why delete and re-create the window? Does
> that perhaps represent some kind of optimization? It's invisible to the
> user in this case, so I don't mind, but I don't understand why it should
> be done.

Yes, it's invisible as long as Emacs doesn't refresh the display between the
time when you hit `d' and the next function call which causes Emacs to
re-enter the debugger.  Sadly, contrary to what happens for window where
window creation/deletion is propagated to the display upon redisplay, frame
creation/deletion is effected immediately so the iconify/deiconify causes
flashing whereas the deletion&re-creation of the window is usually
not visible.

> I still don't see why any of the debugger commands should delete and
> recreate, or iconify and deiconify, or erase and redraw ... windows and
> frames. As long as you are in the debugger, it should remain displayed, IMO.
> When you quit, the debugger buffer and its window or frame (if one-window-p)
> should be deleted completely.

There's no way to know, when you quit, that you're quitting "for ever".
In practice, when I hit `q' it's quite frequent that I'll be getting back to
the debugger pretty soon.
Deleting the buffer+window+frame means losing the size&placement
information, which I find very annoying.


        Stefan