Re: Better handling of window margins

[martin rudalics <rudalics@gmx.at>]

 > Size in pixels is not the main part of what I proposed.  I only
 > mentioned pixels because the margins can display images, and there's
 > no easy way of knowing how many columns an image will take.
 >
 > The main part of my proposal is that each request for a window margin
 > will specify both the margin size and the size of the stuff that will
 > be displayed there.  Two values, not one.

OK.

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

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

martin