Re: "after" variable watchers

[Stefan Monnier <monnier@iro.umontreal.ca>]

martin rudalics [2021-05-18 17:10:47] wrote:
>>> window_updeco_window is called indirectly from all places that change a
>>> window's decorations, font or size.
>>
>> Would it make sense to call it more lazily, e.g. as part of redisplay
>> (basically, the watchpoints would just set some dirty bits and then at
>> the beginning of redisplay you'd then run `window_updeco_window` on
>> those windows with the dirty bit set)?
>
> That was my first approach given our current implementation of watch
> points.  I spent a couple of weeks on it but it didn't really work out.
> Between the time a variable is set and the time the setting is applied,
> the "realized" values would be inaccurate.  These values are, however,
> needed in too many places before we start redisplaying a window.

What was the problem you encountered when you tried to add:

    if (<dirty>) window_updeco_window (...);

to the getters of the realized values?

> I do not want to exclude that such a lazy approach could work.  But it
> would require more profound changes to the way window sizes and
> decorations are processed than the approach based on "after" variable
> watchers.

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.


        Stefan