Re: display-buffer cleverness - how to tame?

[martin rudalics]

> Yes, I read it. No, I don't see any such "step-by-step operative description".
> I'm looking at the latest pretest. If you've updated the manual since then, 
then
> no, I haven't read your update.

This part was written by Eli and I think it's a splendid example of how
to combine the operational description of the buffer displaying process
with the description of the variables that affect this process.  If you
don't see that, then I assure you that I can hardly do any better.

> There is this sentence: "Precisely how `display-buffer' finds or creates a
> window depends on the variables described below." And then the variables are
> described.

At the end of each description Eli explains how the process continues.

> IOW, we say that how it does it what it does depends on the variables. But I
> don't see that "how" or even that "what" described in any "step-by-step
> operative description".
>
> Sorry; it's not clear to me from reading that doc (or the doc strings).

Please give us at least one or two concrete examples.

> Yes, it's there. I can dig out that meaning after several readings. But this
> description of `split-height-threshold' is hard to follow:
>
> "If no window is tall enough, or if the value of
> this variable is `nil', `display-buffer' tries to split some window
> horizontally, subject to restrictions of `split-width-threshold'
> (see below).  If splitting horizontally is impossible too,
> `display-buffer' splits a window vertically only if it's the only
> window on its frame and not the minibuffer window, and only if
> `pop-up-windows' is non-`nil'."
>
> If that description is combined with the description of 
`split-width-threshold',
> then yes, it follows that when both are nil then in most cases no window is
> split. But it takes some digging to get that.

As a matter of fact that happened because I tried to be more concrete.
If I omit such details you'll tell me that you miss them :-(

> So `split-window-preferred-function' is now always a function? That would seem
> to change quite a lot.

Hardly anything.

> Looking at the `window.el' code in the pretest, I cannot imagine what the
> resulting behavior change will be. Will `window--try-to-split-window' always 
use
> `split-window-preferred-function'?

Yes, provided the frame is splittable.

> Will the default value of that option then be
> some function that calls `window--splittable-p' and takes into account the two
> thresholds somehow? Presumably, but just what/how?...

The default is now the new function `split-window-sensibly' which has
been split off from `window--try-to-split-window'.

> I think I'll wait and see the new code and doc, before trying to figure out 
the
> behavior.
>
>>  >>  > If that's not true, then (besides fixing the doc), how can
>>  >>  > `split-window-preferred-function' prevent window splitting
>>  >>  > altogether?
>>  >>
>>  >> With the new code by always returning nil.
>>  >
>>  > OK. I guess I'll need to try the new behavior, after your
>>  > recent changes, before trying to fix my code to make use of
>>  > the new `display-buffer'.
>>
>> There won't be any substantial change but the one mentioned above, so
>> you can try it already with the current code.
>
> The current (pretest) code has `split-window-preferred-function' = nil. If 
that
> won't be nil, then with what default-value function would I replace it, in 
order
> to "try it" (the new behavior)?

`split-window-sensibly'.

martin