Re: Better handling of window margins

[Eli Zaretskii]

> Date: Fri, 04 Dec 2015 09:07:56 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
> 
>  >> If modes can specify their needs for each window they act on, the
>  >> overhead will be encapsulated in calculating a window's minimum width.
>  >
>  > How can you encapsulate what an unknown mode will want to do?
> 
> The unknown mode will have posted its display-width as you suggested.
> ‘window-min-size’ (better ‘window--min-size-1’) will then, instead of
> calling ‘window-margins’, call a function say ‘window-min-margins’ which
> returns the sum of the display-widths of all modes that want to display
> something in the margins of that window.

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 are still talking about splitting windows here, right?

>  >> If we can't manage that, then modes will also have to intervene every
>  >> time we set a window's fringes or scroll-bar width or adjust its right
>  >> trailing edge.  I'm afraid that mode authors won't want to do that.
>  >
>  > Sorry, you lost me.  What do fringes and scroll bars have in common
>  > with the issue at point?  Do you envision a window with 20-column wide
>  > fringes or something?
> 
> 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?