Re: "after" variable watchers

[martin rudalics <rudalics@gmx.at>]

 > What was the problem you encountered when you tried to add:
 >
 >      if (<dirty>) window_updeco_window (...);
 >
 > to the getters of the realized values?

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.

 > You obviously know more about this code, so I can't say much more.
 > I was just pointing in the direction of using dirty "bits" (it's
 > actually often better to represent dirty state via things like our
 > buffer ticks than via actual `dirty` bits) because it's the standard
 > solution for such problems: experience has usually shown that decoupling
 > the setting of vars from the execution of the consequences usually leads
 > to a much more solid design where it's much easier to deal with problems
 > of inf-loops or (in)efficiency.

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.  A `window-body-size' or `window-min-size'
call after that would then require to run window_updeco_window too.
Identifying all sorts of such getters is not a very reliable process.
(BTW, identifying all sorts of setters is not that easy either -
face-remap.el alone contains six calls for this.)

I do use a quite extended mechanism for identifying a "dirty" state when
trying to catch changes in windows (see run_window_change_functions) so
I think that I'm not allergic to such a solution.  But in the case at
hand I simply failed to integrate it well in the existing framework.

martin