[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
de-iconify.
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
sexp.
`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)
call-interactively(describe-variable)
After `c':
Debugger entered--returning value: nil
buffer-live-p(nil)
* byte-code("...")
* describe-variable(features)
call-interactively(describe-variable)
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.
Sadly.
> 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
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, (continued)
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/06
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/06
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/06
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/06
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/06
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/06
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/06
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/07
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/08
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/08
- RE: debugger with pop-up-frames non-nil: keeps creating new frames,
Drew Adams <=
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/08
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/10
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/10
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/10
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/10
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/10
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/17
- Re: debugger with pop-up-frames non-nil: keeps creating new frames, Stefan Monnier, 2005/06/17
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/17
- RE: debugger with pop-up-frames non-nil: keeps creating new frames, Drew Adams, 2005/06/21