[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: display-buffer-change
From: |
Stefan Monnier |
Subject: |
Re: display-buffer-change |
Date: |
Sun, 09 Sep 2007 15:33:19 -0400 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/23.0.50 (gnu/linux) |
>> 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.
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?
>> 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.
>> 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.
I don't think that's going to help. This variable is almost never
used/obeyed :-(
And I don't think it'd help the OP anyway because he doesn't want to go
a configure such things. And the window shouldn't be fixed-size anyway
(you should still be able to resize it with balance-window, for example).
>> 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.
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?
Stefan
- Re: bug of display-table & make-glyph-code, (continued)
- Re: bug of display-table & make-glyph-code, Chong Yidong, 2007/09/05
- Re: bug of display-table & make-glyph-code, martin rudalics, 2007/09/06
- Re: bug of display-table & make-glyph-code, Stefan Monnier, 2007/09/06
- Re: bug of display-table & make-glyph-code, martin rudalics, 2007/09/06
- Re: bug of display-table & make-glyph-code, Stefan Monnier, 2007/09/06
- Re: bug of display-table & make-glyph-code, martin rudalics, 2007/09/06
- Re: bug of display-table & make-glyph-code, Stefan Monnier, 2007/09/07
- Re: bug of display-table & make-glyph-code, martin rudalics, 2007/09/07
- Re: bug of display-table & make-glyph-code, Stefan Monnier, 2007/09/07
- Re: display-buffer-change (was Re: bug of display-table & make-glyph-code), martin rudalics, 2007/09/08
- Re: display-buffer-change,
Stefan Monnier <=
- Re: display-buffer-change, martin rudalics, 2007/09/09
- Re: display-buffer-change, David Kågedal, 2007/09/10
- Re: display-buffer-change, martin rudalics, 2007/09/10
- Re: display-buffer-change, David Kågedal, 2007/09/10
- Re: display-buffer-change, martin rudalics, 2007/09/10
- Re: bug of display-table & make-glyph-code, Richard Stallman, 2007/09/07
- Re: bug of display-table & make-glyph-code, Richard Stallman, 2007/09/06
- Re: bug of display-table & make-glyph-code, Glenn Morris, 2007/09/06
- Re: bug of display-table & make-glyph-code, Kim F. Storm, 2007/09/05
- Re: bug of display-table & make-glyph-code, martin rudalics, 2007/09/05