bug#32825: 27.0.50; Deterministic window management

[Michael Heerdegen]

martin rudalics <rudalics@gmx.at> 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.