Re: display-buffer cleverness - how to tame?

[martin rudalics <rudalics@gmx.at>]

 > 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