bug#20189: 25.0.50; Feature request: Alternative split-window-sensibly functions

[martin rudalics <rudalics@gmx.at>]

 > My understanding of the current logic is that 'display-buffer' is
 > generally used for short-lived windows that are intended to be deleted
 > a short time after the split.

`display-buffer' is, for example, used in `find-file-other-window' so
it's also used for making long-lived windows.

 >> (1) That version would prefer horizontal splits as above.
 >>
 >> (2) I want either horizontal or vertical splitting but not both, i.e.,
 >>      the layout should always be Nx1 or 1xN windows.
 >>
 >> (3) A window may get split horizontally not if it's wider/taller than
 >>      `split-width-threshold'/`split-height-threshold' but instead when
 >>      its width/height *after* the split followed by `balance-windows'
 >>      is larger than or equal to (/ split-{width,height}-threshold 2).
 >>
 >> (4) The single-window exception of `split-height-threshold' still
 >>      holds, so in frames with just one window a vertical split is
 >>      performed even though that window is actually too small according
 >>      to the rules above.
 >
 > Maybe I misunderstand, but doesn't (2) contradict (1)?

I don't think so.  Tassilo just prefers side-by-side windows, if the
frame dimensions permit them.

 > And why is (1) a good idea anyway?  Why not have a more optimal split,
 > whereby (for example) the larger dimension is preferred?

`display-buffer' proposes to split the largest window first.  This
choice cannot be influenced by `split-window-preferred-function'.
Although the latter may deliberately try to split another window
instead.

 > It is also possible that in some cases the caller of
 > split-window-sensibly could provide the requested dimensions in
 > advance.

The `window-width' and `window-height' alist members of `display-buffer'
can be used to provide them.

martin