[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 09:18:05 -0700

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

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?

    > That is, I use the same steps 1-6 as before, except this time
    > is considered a special-display buffer: emacs -q, load the patched cvs
    > debug.elc, set variables pop-up-frames and
    display-buffer-reuse-frames to
    > `t'.

    Yes, the special-display buffer case is what I've been using
    for years ;-)

Me too. But it doesn't work correctly now.

Do you use Windows? In my environment (Windows XP), it simply iconifies;
period. I then have to reach into the task bar and manually deiconify it,
just to continue. At the next step, it iconifies again, I manually deiconify
again... Very annoying.

    > I also tried substituting `quit-window' for `bury-buffer' in
    the code.  That
    > solves the iconification problem, but the frame is
    effectively erased and
    > redrawn at each debugger `d', producing a flashing effect.

    With bury-buffer I see the flashing.

Do you use Windows? If not, that might be the difference.

In any case, flashing is not good either. If it were, I would just hack the
code to use quit-window and be done with it.

    > 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. It iconifies with every
command, including `d'. But, aside from `d', why should it iconify with `q'
or `c'?

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. On Windows, when a frame is iconified, the user sees
it zip across the display into the task bar to become an icon. This is not
something you want to see when you quit the debugger. And the icon then
remains in the task bar - when you quit the debugger, you do not want the
debugger frame to continue to exist, whether raised or as an icon.

Even if iconifying were OK for `q', why do that when you hit `c'? You are
still using the debugger window/buffer/frame, no? Why would you want to bury
or iconify the buffer with `c'? It should remain displayed, so you can use

    >  - Why we would want to use bury-buffer here at all? Why not
    leave it, since
    > we are still in the debugger? What was wrong with the way it
    worked before
    > (say, in Emacs 20)?

    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? If any
debugger command means "do not leave; I'm still using the debugger" it's `d'
(digging deeper into a function call).

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

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

In the frame case, it produces flashing (when it doesn't iconify), which is

    Just like the iconify/deiconify flashing you see
    with quit-window.

The two should not have similar behaviors in this respect. Deleting and
re-creating a window is not noticeable by the user. Iconifying, or erasing
and then redrawing, a frame is more than noticeable: it is annoying.

    Can you try the additional patch below?

It now appears fixed for `d', but both `c' and `q' still iconify the buffer
(and leave it iconified, at least in Windows). With `q', you get a (useless,
no, bothersome) iconified buffer with nothing in it, since you have quit.

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.

reply via email to

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