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

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

Re: window-size constraints

[martin rudalics]

 > 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.

We'd still have to decide whether and how to honor buffer-local values
of variables like `window-min-height' or `split-height-threshold'.

 > 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.

When the window configuration changes Emacs often tries to preserve
proportionally the size of non-fixed size windows as faithfully as
possible.  How would `balance-windows-area' help here?  Doesn't it try
to give all windows the same size?  The doc-string isn't of much help
here :-(

Re: window-size constraints

[Stefan Monnier]

>> 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.

> We'd still have to decide whether and how to honor buffer-local values
> of variables like `window-min-height'

Of course, we have to honor it.  It's already defined as buffer-local.
It should be easy/trivial to support.  At least window-area-factor was
trivial and I see no reason why window-min-height should be any
more difficult.

> or `split-height-threshold'.

I'm not sure I'd want to include display-buffer in this system, tho
I guess it might make sense.

> When the window configuration changes Emacs often tries to preserve
> proportionally the size of non-fixed size windows as faithfully as
> possible.  How would `balance-windows-area' help here?

I'm not referring to the functionality it provides, but to the way it
does it, i.e. to its code.  But it's really not that important: just let
the C code do its thing, hoping it won't mess up majorly (i.e. it won't
delete windows that don't absolutely need to be deleted), and then do
the actual size-choice in Elisp by trying to resolve the CSP.

> Doesn't it try to give all windows the same size?

Yes, except for the window-area-factor detail, but again, this
isn't relevant, really.


        Stefan

Re: window-size constraints

[martin rudalics]

 >>We'd still have to decide whether and how to honor buffer-local values
 >>of variables like `window-min-height'
 >
 > Of course, we have to honor it.  It's already defined as buffer-local.

In what sense is it defined as buffer-local?

 > It should be easy/trivial to support.  At least window-area-factor was
 > trivial and I see no reason why window-min-height should be any
 > more difficult.

But `window-area-factor' is not customizable.  In window_min_size_2 I
currently use Fbuffer_local_value as

	  int min_size = (BUFFERP (w->buffer)
			  ? XINT (Fbuffer_local_value (Qwindow_min_height,
						       w->buffer))
			  : window_min_height);

Is that TRT?

 >>or `split-height-threshold'.
 >
 > I'm not sure I'd want to include display-buffer in this system, tho
 > I guess it might make sense.

We could rule out splitting all windows showing a particular buffer by
setting `split-height-threshold' and `split-width-threshold' nil for
that buffer.  Isn't that something we want in another context?

 >>When the window configuration changes Emacs often tries to preserve
 >>proportionally the size of non-fixed size windows as faithfully as
 >>possible.  How would `balance-windows-area' help here?
 >
 > I'm not referring to the functionality it provides, but to the way it
 > does it, i.e. to its code.  But it's really not that important: just let
 > the C code do its thing, hoping it won't mess up majorly (i.e. it won't
 > delete windows that don't absolutely need to be deleted), and then do
 > the actual size-choice in Elisp by trying to resolve the CSP.

Resolving size constraints is harder than balancing windows.  Moreover
it should be history sensitive: For example, when a window gets deleted
it's entire size should be usually given to its previous sibling.  At
least this would hold for `with-output-to-temp-buffer' windows.