bug#32825: 27.0.50; Deterministic window management

[martin rudalics <rudalics@gmx.at>]

 >> So you mean that if Emacs can't fulfill a 'window-height' contract for
 >> a new window below the selected one, it shouldn't make a new one in
 >> the first place?  Then with an an alist entry called 'min-height' we
 >> could rewrite 'display-buffer-below-selected' as follows:
 >
 > Thanks, I tried and it's going without a hitch.

OK.  This means we will have to change 'display-buffer-pop-up-window'
and 'display-buffer-at-bottom' accordingly.

 >> But would we (re-)use a window if it is not as large as 'min-height'?
 >> Would we try to enlarge such a window?  As far as we can?
 >
 > Hmm, enlarge looks like a reasonable choice.

Mine was an ill-posed question.  What we have to do is:

(1) Decide whether a specific window can be (re-)used.  Should we
refute it when the window cannot be enlarged to 'min-height' lines?
The decision would have to be made via 'window-resizable-p' and its
IGNORE argument set to the window itself so we can, for example,
(re-)use a preserved size window showing some other buffer.

(2) Actually resize that window via a 'window-height' entry.  This is
independent from (1).  Processing a 'window-height' entry is just some
sort of bonus work 'display-buffer' does for the convenience of the
user.  It in now way affects the decision which window is chosen.

So please think of any bad consequences of what we decide in (1) like
not using _any_ window on the selected frame because none of them fits
the 'min-height' constraint.  Consider a default two windows frame
where the size of the selected window is preserved.

martin