window-size constraints (was: bug#410: 23.0.60; display-buffer regression)

[Stefan Monnier]

> I'd like to make the window code resilient in a way that applications
> like calendar can naturally set `window-size-fixed'.  As a consequence,
> `display-buffer' wouldn't change the calendar window's size even it were
> larger than the new window.  Setting `window-size-fixed' can currently
> result in unexpected behavior.  Fixing this is non-trivial.

> Also I'd like to give `split-height-threshold' and `window-min-height'
> buffer-local semantics and maybe add a `window-max-height' variable so
> to do `fit-window-to-buffer' and `shrink-window-if-larger-than-buffer'
> implicitly during each window configuration change.  `window-min-height'
> equalling `window-max-height' for a particular buffer would then imply
> `window-size-fixed' for that buffer.

> Eventually, a user should be able to change window configurations
> arbitrarily with the calendar window always keeping its original size
> (unless there's no other way, obviously).

I think we should go in the direction of "constraints", which would take
the form of Elisp functions.  Every configuration change would
correspond to adding&removing constraints, and then try and solve the
resulting CSP.  Constraints would come with priorities so that in the
case the CSP has no solution, we can choose which constraint(s)
to break, or alternatively, the satisfaction of a constraint would not be
boolean, so the goal would be to try and maximize the satisfaction.

While writing the balance-window-area code, I went through several
iterations, and some of them just tried to move window-boundaries in
arbitrary ways, then measure the "balance-factor" (basically, the
window-area variance) and little by little move towards
a local optimium.

Also, I have some uninstalled code that uses
window-configuration-change-hook to preserve the
`balance-window-area'ness of a frame when windows are created/deleted.


        Stefan