[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Better handling of window margins
From: |
martin rudalics |
Subject: |
Re: Better handling of window margins |
Date: |
Fri, 04 Dec 2015 11:21:22 +0100 |
> And how will this help in deciding how to split a window, when you
> cannot predict how the margins will change (or _whether_ they will
> change) as result of the split?
We never can predict such things. For ‘linum-mode’ the display-width of
a window's margin will change when you show another buffer in that
window and that other buffer has 10000 lines and the buffer you showed
before has 5.
If ‘split-window’ is supposed to show the buffer of the original window,
the display-width of the margin is not supposed to change. And that's
everything ‘split-window’ can care about. If we are going to display
another buffer in the new window, all bets are off.
Years ago I proposed to introduce a function ‘make-window’ which would
accept as argument the buffer of the new window. ‘make-window’ could
then have determined the minimum width of that window from buffer local
variables of the buffer to show there. Nobody was interested.
Anyway. Modes like ‘linum-mode’ which specify the display-width of the
margin in ‘post-command-hook’ could defeat any prediction unless they
provide a function that would allow ‘split-window’ to calculate the
expected display-width of the margin.
> We are still talking about splitting windows here, right?
And about resizing windows, right?
>> No. I meant that enlarging a fringe by a few pixels or calling
>> ‘adjust-window-trailing-edge’ should probably be allowed to reduce the
>> margin-width for that window while preserving the display-width of its
>> margins. Currently these work by the simple magic that the text area is
>> usually large enough so it can be shrunk when the window gets resized or
>> its fringes enlarged.
>
> OK, but how does this lead to "modes will also have to intervene every
> time we set a window's fringes" part?
Because the decision whether we can enlarge the fringes of a window is
also based on the size of the window's margins (see set_window_fringes).
So if a mode should be allowed to affect the behavior of ‘split-window’
based on how it wants its margins to behave in the old or new window, it
should be also allowed to affect the behavior of ‘set-window-fringes’,
for example, by reducing the margin-width when enlarging a fringe.
martin
- Re: Better handling of window margins, (continued)
- Re: Better handling of window margins, Stefan Monnier, 2015/12/07
- Re: Better handling of window margins, John Wiegley, 2015/12/07
- Re: Better handling of window margins, Stefan Monnier, 2015/12/07
- Re: Better handling of window margins, John Wiegley, 2015/12/07
- Re: Better handling of window margins, martin rudalics, 2015/12/04
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/04
- Re: Better handling of window margins,
martin rudalics <=
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/04
- Re: Better handling of window margins, martin rudalics, 2015/12/04
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/04
- Re: Better handling of window margins, martin rudalics, 2015/12/04
- Re: Better handling of window margins, Joost Kremers, 2015/12/02
- Re: Better handling of window margins, Eli Zaretskii, 2015/12/03
Re: Better handling of window margins, Joost Kremers, 2015/12/02
Re: Better handling of window margins, John Wiegley, 2015/12/15