bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

>> The problem with this approach is as follows: The list of next buffers
>> is usually empty because it contains only the buffers visited while
>> navigating the list of previous buffers backwards in time.  It's main
>> purpose is to revert any overshooting during such navigation.  But
>> this means that when you add your temporary buffer to the (usually
>> empty) list of next buffers, overshooting while reverting the
>> overshooting will get you to that temporary buffer immediately.
>
> What buffer does it show now in this case?  Is it a more predictable
> buffer than would be in case of a previously displayed temporary buffer?

Currently we remove the buffer in question (*Backtrace*) entirely from
all buffer lists so it isn't found by the switch-to-prev/next-buffer
routines, the list of next buffers is usually empty and it will do ...

>>       If there is no recent invocation of `switch-to-prev-buffer' that
>>       can be undone, this function tries to show a buffer from the
>>       buffer list of the frame WINDOW appears on ...
>
> And this is usually some random unpredictable buffer.

Correct.  But we cannot well go to the end of the list of previous
buffers instead.  That list could be even empty.  And traditionally
Emacs chooses some random buffer here although the order is a bit
determined by previous 'bury-buffer' calls.

>> but this comes from an attempt to model buffer switching like 'undo'
>> does.
>
> undo/redo is a good analogy.

Unfortunately, undo/redo does not stop either where my intuition would
want it.  In particular, I can't tell it to "now redo things until
you've got me back the state with the maximum of changes of the
existing code since I started editing this".  There's some fuzziness
missing.  Maybe some snapshots of my past editing activity ...

martin