[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: display-buffer-change
From: |
martin rudalics |
Subject: |
Re: display-buffer-change |
Date: |
Sun, 09 Sep 2007 23:42:54 +0200 |
User-agent: |
Mozilla Thunderbird 1.0 (Windows/20041206) |
>>>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.
- Re: bug of display-table & make-glyph-code, (continued)
- 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, 2007/09/09
- Re: display-buffer-change,
martin rudalics <=
- 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
- Re: bug of display-table & make-glyph-code, Kim F. Storm, 2007/09/05