Subject: Re: bug#32825: 27.0.50; Deterministic window management

From: Michael Heerdegen <[email-masked]>
Date: Sun, 30 Sep 2018 13:40:30 +0200

martin rudalics <[email-masked]> writes:

> To be honest, I don't grok the idea of 'debugger-previous-window' in
>
> 	      (pop-to-buffer
> 	       debugger-buffer
> 	       `((display-buffer-reuse-window
> 		  display-buffer-in-previous-window)
> 		 . (,(when (and (window-live-p debugger-previous-window)
> 				(frame-visible-p
> 				 (window-frame debugger-previous-window)))
> 		       `(previous-window . ,debugger-previous-window)))))
>
> any more and am afraid to do more damage than fix anything.

'debugger-previous-window' had been introduced because the debugger
buffer jumped around in a frame's windows every time the debugger was
reentered - e.g. when you stepped through code with d, d, ..., and there
were multiple windows in the selected frame, with every d hit, the
debugger would appear in a different window.

AFAIR the fix was rather simple: The var `debugger-previous-window'
is updated as long as the debugger will be reentered - when leaving the
debugger, it is reset to nil.

The code you cited just implements that the variable's value is
respected.

Our issue here is a different one: we want the debugger to use the
latest selected window for a _new_ debugger session.

I'm not sure if we could reuse 'debugger-previous-window' for fixing
this issue, but AFAIR it was important that the variable is reset to nil
after a debugger session is finished.  The answer can probably be found
in the message archives.

Michael.