[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Drew Adams
Subject: RE: debugger with pop-up-frames non-nil: keeps creating new frames
Date: Wed, 8 Jun 2005 13:56:09 -0700

    > 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

Good. Sounds like progress.

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

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.

In the case of `q', I've quit the debugger. I don't want to iconify the
(empty) debugger buffer (frame) - I want to delete it altogether. Why would
you want an iconified empty debugger frame?

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

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

`q' leaves the debugger. It should leave it completely. Not only do I not
want an empty *Backtrace* buffer/window/frame staring at me; I also do not
want an iconified empty *Backtrace* frame hanging around. It's even harder
to get rid of interactively than a raised frame.

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

Yes, I've read them.

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?

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

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

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

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. If you want to remove it when the buffer is empty, that would be
OK. That would take care of both `q' and `c' - there is no reason for the
buffer to exist if it is empty, so emptiness should be a necessary &
sufficient test to trigger its deletion.

In Emacs 20 the *Backtrace* frame doesn't disappear after even `q', but I
can always do `C-x 0' to delete the frame. (My version of `delete-window'
deletes the frame if one-window-p.) It's a *lot* less annoying to just do
`C-x 0' when I'm done with the debugger than it is to wrestle with flashing
or iconifying frames at each debugger step.

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

I don't understand this at all. I don't see an empty buffer until I'm back
up tot the top level. After I use `c', the buffer shows the result of the
current evaluation, plus all of the trace steps still to be done, below it.

Here's what I see before and after `c' on the sexp buffer-live-p(nil) when
debugging describe-variable:

Before `c':

Debugger entered--entering a function:
* buffer-live-p(nil)
* byte-code("...")
* describe-variable(features)

After `c':

Debugger entered--returning value: nil
* byte-code("...")
* describe-variable(features)

The buffer is not empty.

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

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

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

Regardless, from a user point of view, the buffer should never be empty
until the top level is reached again (no [] in mode line), and the buffer
should never be hidden/deleted/iconified unless it is empty. When it is
empty, it should be left as is or deleted, certainly not iconified.

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

So we're weighing annoyances, here. If your annoyance is that important, how
about going back to the Emacs 20 behavior of just leaving the frame (not
window) displayed (no loss of size&placement info)? I have no problem
getting rid of the frame with `C-x 0', and if I want to keep it (to do more
debugging), then I just leave it.

If you don't want to delete the frame when the debugger is exited (from a
user point of view), then consider making it invisible - that should let you
keep the size&position info. Iconifying is not a solution. And if you do
that, please do it only after the buffer is empty (top level), not at each
debugger step.

 - Drew

reply via email to

[Prev in Thread] Current Thread [Next in Thread]