Re: display-buffer-change (was Re: bug of display-table & make-glyph-code)

[martin rudalics <rudalics@gmx.at>]

Stefan Monnier schrieb:
 >>>I must have lost too much context: I do not understand the
 >>>above description.  Can someone spell it out in baby-steps for my poor
 >>>excuse for a brain?
 >
 >
 >>The OP explained it as follows:
 >
 >
 >>>Split an emacs frame in two windows showing buffers A and B:
 >>>
 >>>+-------------+
 >>>|             |
 >>>|      A      |
 >>>|             |
 >>>+-------------+
 >>>|             |
 >>>|      B      |
 >>>|             |
 >>>+-------------+
 >>>
 >>>While in the lower window, run
 >>>
 >>>(set-window-dedicated-p (selected-window) t)
 >>>
 >>>Now, in the upper window, run
 >>>
 >>>(display-buffer "C")
 >>>
 >>>In Emacs 21, this will be the result:
 >>>
 >>>+-------------+
 >>>|      A      |
 >>>+-------------+
 >>>|      C      |
 >>>+-------------+
 >>>|             |
 >>>|      B      |
 >>>|             |
 >>>+-------------+
 >>>
 >>>In Emacs 22, this will be the result:
 >>>
 >>>+-------------+
 >>>|             |
 >>>|      C      |
 >>>|             |
 >>>+-------------+
 >>>|             |
 >>>|      B      |
 >>>|             |
 >>>+-------------+
 >>>
 >>>In Emacs 22 with split-heigh-threshold=10, this will be the result:
 >>>
 >>>+-------------+
 >>>|             |
 >>>|      A      |
 >>>|             |
 >>>+-------------+
 >>>|      B      |
 >>>+-------------+
 >>>|      C      |
 >>>+-------------+
 >>>
 >
 >
 >>What he apparently wants is window B always display the same buffer, stay
 >>below all other windows, and not change its size.
 >
 >
 > I guess I see the following problems:
 > 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.

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


 > 2 - "dedicated" is mostly meant to cause deletion of the buffer to also
 >     cause deletion of the window.  It says nothing about the window having
 >     a fixed size or being non-splittable.

Agreed.

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

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