Re: window-size constraints

[martin rudalics <rudalics@gmx.at>]

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