`q' in debugger with a dedicated *Backtrace* window

`q' in debugger with a dedicated *Backtrace* window

[Drew Adams]

I use a dedicated window for the debugger: non-nil pop-up-frames and non-nil
window-dedicated-p.

In Emacs 22, when I use `q' in the debugger, the debugger frame is deleted
(disappears). This does not happen in Emacs 20 or 21. To me, this is an
annoying bug. Users might well position or resize the debugger frame
manually or with custom code. `q' means to quit the debugger, but it doesn't
mean to throw away the debugger buffer or frame. The debugger might well be
reentered later, and the user might want to reuse the same frame.

This appears to be the relevant code (in monster function `debug'). In Emacs
21, the code is simply this, which leaves the *Backtrace* frame empty and
available for future use - just what I want:

;; Still visible despite the save-window-excursion?  Maybe it
;; it's in a pop-up frame.  It would be annoying to delete and
;; recreate it every time the debugger stops, so instead we'll
;; erase it but leave it visible.
(save-excursion
  (set-buffer debugger-buffer)
  (erase-buffer)
  (fundamental-mode))

I agree with that comment, BTW: it *is* now annoying that it is deleted and
recreated in Emacs 22 - the frame, that is.

In Emacs 22, that code has become the following:

(with-current-buffer debugger-buffer
  (erase-buffer)
  (fundamental-mode)
  (with-selected-window (get-buffer-window debugger-buffer 0)
    (when (and (window-dedicated-p (selected-window))
               (not debugger-will-be-back))
      ;; If the window is not dedicated, burying the buffer
      ;; will mean that the frame created for it is left
      ;; around showing some random buffer, and next time we
      ;; pop to the debugger buffer we'll create yet
      ;; another frame.
      ;; If debugger-will-be-back is non-nil, the frame
      ;; would need to be de-iconified anyway immediately
      ;; after when we re-enter the debugger, so iconifying it
      ;; here would cause flashing.
      ;; Use quit-window rather than bury-buffer to quieten
      ;; Drew Adams.  --Stef
      (quit-window))))

To speak to the comment about Drew Adams: Before this was changed to
quit-window, things were even worse - iconifying (with the flashing
mentioned) and bury-buffer were tried. Multiple debugger frames were
created, reproducing like rabbits.

Stefan fixed that problem by using quit-window, which is much better than
the previous Emacs 22 behavior - but it is still worse than what Emacs 20
and 21 did: *nothing*.

Could we please go back to the Emacs 21 behavior in the case of a dedicated,
one-window-p frame - just leave the buffer and frame alone?

If not, please leave the code alone. quit-window is a pain for me, but it is
a lot less of a pain than flashing, iconifying, or burying - I don't want to
risk having something like that again. If we could make the change back to
the simpler behavior for dedicated windows, that would be great. Thanks.

BTW - Judging by appearances, the `debug' function code is a bit haggard. It
seems to have been poked and tweaked to death, without ever having been
rewritten.

Re: `q' in debugger with a dedicated *Backtrace* window

[Stefan Monnier]

> (with-current-buffer debugger-buffer
>   (erase-buffer)
>   (fundamental-mode)
>   (with-selected-window (get-buffer-window debugger-buffer 0)
>     (when (and (window-dedicated-p (selected-window))
>                (not debugger-will-be-back))
>       ;; If the window is not dedicated, burying the buffer
>       ;; will mean that the frame created for it is left
>       ;; around showing some random buffer, and next time we
>       ;; pop to the debugger buffer we'll create yet
>       ;; another frame.
>       ;; If debugger-will-be-back is non-nil, the frame
>       ;; would need to be de-iconified anyway immediately
>       ;; after when we re-enter the debugger, so iconifying it
>       ;; here would cause flashing.
>       ;; Use quit-window rather than bury-buffer to quieten
>       ;; Drew Adams.  --Stef
>       (quit-window))))

> To speak to the comment about Drew Adams: Before this was changed to
> quit-window, things were even worse - iconifying (with the flashing
> mentioned) and bury-buffer were tried. Multiple debugger frames were
> created, reproducing like rabbits.

AFAIK, 90% of the flashing problem was fixed by checking
debugger-will-be-back.  The 10% remaining is only for the case where
a breakpoint is in the middle of a loop.
As for reproducing like rabbits, this was before the (window-dedicated-p
(selected-window)) check (AFAIK, again), so it's been fixed 100%.

So if I understand correctly you're opposed to bury-buffer because in some
cases it causes flashing.  I don't know about you, but I find flashing
*much* less problematic than deletion/recreation of a frame.

You seem to have forgotten the main reason why you didn't want bury-buffer:
you didn't want a iconified frame left around.

I guess I should just revert to bury-buffer to add an option
debugger-for-drew-adams.  This way you'll stop whining and I'll get the
saner behavior.

> quit-window is a pain

That's what I told you when you kept begging for it.


        Stefan

RE: `q' in debugger with a dedicated *Backtrace* window

[Drew Adams]

> > quit-window is a pain

You snipped this part: "but it is a lot less of a pain than flashing,
iconifying, or burying"

> That's what I told you when you kept begging for it.

quit-window is much better than bury-buffer, for my own use. I said from the
beginning, however, that the Emacs 20/21 behavior was fine with me - I can
delete the frame when I'm done with it.

I found automatic iconifying (from bury-buffer) annoying; you found leaving
the frame present (as in Emacs 20/21) annoying. quit-window is one middle
way.

But why not add a user option, as both you and I proposed more than once?
That is, use (funcall debugger-quit-function) in place of (bury-buffer) or
(quit-window) or (do-nothing).

Different users are bound to have different uses of the debugger and
different preferences for its interaction. An option would provide the
necessary flexibility. And yes, you can call the option
"debugger-for-drew-adams" if that makes you feel better. I know I won't be
the only one who uses it, and I don't mind taking credit for it ;-).

If we can't have an option, then please leave the code as is - quit-window
is a lot better than the alternatives I've seen since Emacs 21.

Antinews humor from my email on 2005-06-10:

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

Re: `q' in debugger with a dedicated *Backtrace* window

[Stefan Monnier]

>> > quit-window is a pain
> You snipped this part: "but it is a lot less of a pain than flashing,
> iconifying, or burying"

It can't be less pain than flashing because it causes flashing as well (at
least as much).  Also "burying" is not a visible effect like "iconifying" or
"flashing" so it doesn't make much sense in this list.  All in all, this
list doesn't make much sense, so I snipped it.


        Stefan