Re: display-buffer-change

[martin rudalics <rudalics@gmx.at>]

 >>>0 - it's not clear to me why Emacs chooses to split B rather than A.
 >>>It seems unrelated to the split-height-threshold fix, so we need to look
 >>>into this before being able to determine how best to fix it.
 >
 >
 >>Fget_largest_window returns the largest window and B could be that
 >>window.
 >
 >
 > So it's not always going to behave this way, it depends on details of the
 > current layout.  A shift by 1 line can change the result?

If Fget_largest_window doesn't provide a suitable window Fget_lru_window
kicks in.  Hence we can have all sorts of results.  `display-buffer' is
very stochastic.

 >>>1 - since we're in buffer/window A, it would probably be preferable to place
 >>>buffer C closer rather than further, so in this case after splitting B
 >>>display-buffer should prefer using the top window for C and the bottom
 >>>one for B.
 >
 >
 >>With `split-window' the new window is the lower one, we would lose all
 >>associations for B if we did that.
 >
 >
 > I know.  It'a problem.  Independent from the current one.

It's hardly a problem for the OP.  It's a real pain for me.

 >>>3 - we have window-size-fixed for that.
 >
 >
 >>David: Could you set that for the buffer of your window B and look
 >>whether it gives good results.
 >
 >
 > I don't think that's going to help.  This variable is almost never
 > used/obeyed :-(

I was surprised to find out that it is checked more often than I
thought initially.

 > And I don't think it'd help the OP anyway because he doesn't want to go
 > a configure such things.

Maybe he would.  But it's not useful in general (given the default value
of `split-height-threshold' I don't think people use that either).

 > And the window shouldn't be fixed-size anyway
 > (you should still be able to resize it with balance-window, for example).

100% agreement, but it was your suggestion ;-)

 >>>4 - we don't have window-(un)splittable for that (there's a frame parameter
 >>>to prevent splitting windows in that frame, tho).
 >
 >
 >>Earlier I thought about splitting obey a buffer-local value for
 >>`split-height-threshold'.
 >
 >
 > That would make a lot of sense.  But I don't think it'd help the OP either
 > because it's too detailed a configuration.

The OP would do it.  It's not useful as a general suggestion and it
might be hairy to implement.  Strictly spoken, `display-buffer' would
have to - whenever it tries to split a window - check the buffer-local
value of `split-height-threshold' of the buffer displayed in that window
(or should it be the value of the buffer we want to display?).  Anyway,
just try to convey this in a user manual.

 >
 > To get back to the OP's example scenario, starting from
 >
 >
 >>>>+-------------+
 >>>>|             |
 >>>>|      A      |
 >>>>|             |
 >>>>+-------------+
 >>>>|             |
 >>>>|      B      |
 >>>>|             |
 >>>>+-------------+
 >
 >
 > Why would
 >
 >
 >>>>+-------------+
 >>>>|      A      |
 >>>>+-------------+
 >>>>|      C      |
 >>>>+-------------+
 >>>>|             |
 >>>>|      B      |
 >>>>|             |
 >>>>+-------------+
 >
 >
 > be better than
 >
 >
 >>>>+-------------+
 >>>>|             |
 >>>>|      A      |
 >>>>|             |
 >>>>+-------------+
 >>>>|      B      |
 >>>>+-------------+
 >>>>|      C      |
 >>>>+-------------+
 >
 >
 > and why should it depend on B being dedicated?

I can only speculate: B is my fixed point for compiling, tracing,
debugging, observing or controlling the world.  It's the area of the
screen I'm looking first when I run into troubles.  I don't want it to
change size or position because I wouldn't find it at its usual place in
the shape I got used to.

More likely it's because the OP got used to the A / C / B behavior over
the years.  Maybe he can tell us more.