bug#32825: 27.0.50; Deterministic window management

[martin rudalics <rudalics@gmx.at>]

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

Thanks for the explanation.  If we really have to reset
'debugger-previous-window' to nil (I can't imagine why this would be
necessary) we could still add yet another variable, say
'debugger-last-session-window' and use that in a new session if it's
still alive.  The problem, to recall, is that having *Backtrace* in
the list of previous buffer of a window can be a nuisance - one never
wants to switch to it via 'previous-buffer'.

Whatever we do there: Could you make the 'inhibit-same-window' change
Juri asked for?  I trust you more than myself in this regard.

Also I faintly recall that at least one of your bug reports wrt
debugging and windows was never closed.  Is that true?

martin