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

[martin rudalics]

> 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