bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

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