emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: martin rudalics
Subject: Re: display-buffer-change (was Re: bug of display-table & make-glyph-code)
Date: Sat, 08 Sep 2007 11:22:46 +0200
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]