GNU bug report logs - #8789
23.3; debug backtrace buffer changes window on step-through

Previous Next

Full log

Message #14 received at 8789 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 8789 <at> debbugs.gnu.org, Pete Beardmore <pete.beardmore <at> msn.com>
Subject: Re: bug#8789: 23.3;
	debug backtrace buffer changes window on step-through
Date: Wed, 08 Jun 2011 12:29:30 -0300

> I don't have the slightest idea how to fix this though because I don't
> understand why apparently the *backtrace* buffer is removed from display
> in (1), and what the subsequent fragment

> 	  ;; Kill or at least neuter the backtrace buffer, so that users
> 	  ;; don't try to execute debugger commands in an invalid context.
> 	  (if (get-buffer-window debugger-buffer 0)
> 	      ;; 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 (and maybe hide it) but keep it alive.
> 	      (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.
>                     ;; Drew Adams is not happy with this: he wants to frame
>                     ;; to be left at the top-level, still working on how
>                     ;; best to do that.
>                     (bury-buffer))))
> 	    (kill-buffer debugger-buffer))

> is needed for (despite its detailed comment).  So we need help from
> someone familiar with the debug code :-(

I don't use `d' but I can explain the reason for the above code: when we
exit the debugger, I don't want to leave around an empty
fundamental-mode *Debugger* window (which in my case is a dedicated
window in a separate frame), so I bury it.

BTW, I recently changed the above code in `trunk' so that the
kill-buffer is not called if the buffer was pre-existing.


        Stefan

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.