Re: "after" variable watchers

[martin rudalics <rudalics@gmx.at>]

 >> There are too many implicit "realized" values to make this work nicely.
 >> Think of macros like WINDOW_BODY_PIXEL_WIDTH, WINDOW_BOX_LEFT_EDGE_X,
 >> WINDOW_BOX_RIGHT_EDGE_X, WINDOW_SCROLL_BAR_X or functions like
 >> window_box_height in addition to the things window_updeco_window sets
 >> directly.
 >
 > I don't think I understand this reasoning.  Changes in these values
 > are only visible as result of the next redisplay cycle, no?  So in
 > effect these values "wait" for the next redisplay anyway, right?

window_box_height or its moral equivalents like `window-inside-edges'
should be accessible before that, so a user or an application can make
layout decisions immediately after it has set a decoration.  Currently,
it can do that when invoking `set-window-fringes' or setting the
`left-fringe' parameter of the window's frame.  It cannot do that when
setting `left-fringe-width' of the window's buffer unless it also does a
`set-window-buffer' right away.

 >> Right.  But note that I implicitly call window_updeco_window also
 >> whenever I change a window's size, for example, from adjust_frame_size
 >> after a frame got resized.
 >
 > I think Stefan asks why do we need to do that.  Why not wait for when
 > these values are needed by redisplay, and calculate them only then?

If a specified value does not fit, we should be able react in different
ways:

- When an application asks for a window size that is not large enough to
   accommodate its decorations, we should be able to reject that request
   and signal an error.

- When the WM shrinks our frame so that a particular window is not large
   enough to include all of its decorations, we have to comply and do
   something reasonable to make that window display its contents orderly.

The display engine is not able to distinguish these cases.  And even if
it were, how should it react in the first case?

martin