bug#32825: 27.0.50; Deterministic window management

[martin rudalics]

> Then maybe better to add such buffers to the end of the prev-buffers list
> or to the end of the next-buffers list.

We have that option in 'debugger-bury-or-kill'.  Do you mean to
generalize it?

>>> The second time when the buffer is displayed again in a previous window
>>> is deterministic.  But the first time it is non-deterministic - it's
>>> displayed in a random window.  At least, the user can't predict the
>>> window where it will be displayed - thus the surprise factor.
>>> With get-mru-window instead get-lru-window the place is more
>>> deterministic because the user usually remembers which window is mru.
>>
>> We can add an action alist entry to get the mru (or better
>> mru-not-selected) behavior.  A small deal.
>
> This would be very nice, thanks in advance.

OK.  What do you want to call it, 'windows-to-examine'?  Shall we make
it a list of function/frame pairs defaulting to

'((get-lru-window . nil) (get-largest-window . visible) (get-largest-window . 
0))

where nil stands for whatever

(or (window--frame-usable-p (selected-frame))
    (window--frame-usable-p (last-nonminibuffer-frame)))

returns?  Or do you want to control the DEDICATED and NOT-SELECTED
arguments as well?  I hope that 'get-largest-window', 'get-lru-window'
and 'get-mru-window' are 100% compatible wrt their arguments but
haven't verified that yet.

> I don't understand what an alist entry you mean.  Or you mean adding
> a new alist entry like (default-window . mru-not-selected)?

For example.  To provide the 'windows-to-examine' sketched above you
wouldn't want to specify an action function too.

martin