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.