Re: display-buffer-change

[martin rudalics]

>>>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.