bug#32825: 27.0.50; Deterministic window management

[martin rudalics <rudalics@gmx.at>]

 >>> 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?
 >
 > Yes, it could be moved to a new alist entry.

And act like a time-bomb via a window-parameter (like 'quit-restore')?

 >> OK.  What do you want to call it, 'windows-to-examine'?
 >
 > Too long name.  Maybe better 'try-windows'?  Or 'reuse-window'
 > if this alist entry will be used in display-buffer-use-some-window.

'try-windows' sounds too active for an alist entry - we would have to
use 'windows-to-try' instead.  And let's avoid 'reuse-window' in this
context - it's too ambiguous.  BTW we might also want to add a similar
entry for specifying the window we want to split (which means we could
easily generalize 'display-buffer-below-selected' and
'display-buffer-at-bottom' without having to add new action functions
like 'display-buffer-at-top' ...) and should reserve an appropriate
name for that.

 >> 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 thought it could be a list of window types to try in the specified order,
 > for example:
 >
 > (try-windows . (mru lru largest-visible largest-visible-and-iconified))

... and lru-visible, lru-invisible?  BTW we could allow it to specify
using windows dedicated to another buffer as well.

 >>> 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.
 >
 > But where this alist entry should be customized for all action functions?
 > I guess not in display-buffer-alist that specifies specific buffers.
 > Then where?  Maybe, in display-buffer-base-action with nil action and
 > non-nil alist that will be the default alist for all actions?

Anywhere.  Why should we impose any restrictions here - either for the
user or for the application programmer?

martin