bug#32672: 27.0.50; image resize on window resizing

[martin rudalics]

>> 'window-configuration-change-hook' is a great mess and is not
>> display-related.
>
> It is for the purposes of this discussion, since it's related to
> changes in what windows display which buffers and which frames show
> what windows.

The point I tried to make was that currently running that hook is not
coupled to the eventual display of windows but to things that happen
before.

>> What users really need IMO is a single hook say
>> 'window-state-change-functions' that we'd call in redisplay_internal
>> in lieu of 'window-size-change-functions'.
>
> redisplay_internal knows very little about changes in window
> configurations, so I predict using this new hook will be as messy as
> with the existing ones.

'redisplay_internal' per se should not have to know anything about
these changes.  It would call a simple function that calculates for
every window whether it already existed at the time of the last
redisplay and whether one of its sizes, its position, buffer, point,
or start position changed since then.  In addition we could trace the
state of its parameters and other things like its dedicatedness.

>> We would run it if something in the state of a frame's root window
>> changed (including size changes, changes of the windows' start
>> positions and the selected window) and additionally provide a list
>> of the differences in the frame's previous window state and the one
>> redisplay is about to use.
>
> We'd need to compute this list of changes first, and for that we will
> need a whole slew of new variables and flags.  Currently, redisplay is
> built on the opposite assumption: that each operation which could
> potentially require redrawing some window(s) or frame(s) sets the
> corresponding flags of the object that needs to be redrawn, without
> any "explanation" of why that flag was set.

As I said, redisplay would not have to care about that at all.  It
would simply call 'window-state-change-functions' where it calls
'window-size-change-functions' now.  And running
'window-state-change-functions' would use one boolean set (among
others) instead of where 'run-window-configuration-change-hook' gets
called now and which it resets.  Iff that boolean was set, it would
start to find all windows where a relevant change occurred and run the
functions.  Buffer-locally iff a window shows the buffer for which the
local hook was set and something changed for that window.

The great advantage for users and application programmers would be
that their functions would run once only and only if something really
changed since last redisplay.  Basically, it would extend the current
behavior of 'window-size-change-functions' to all window changing
functions.  And we could extend it in the sense that the users may
customize which changes should run their function without inventing
future hooks for them (admittedly 'add-hook' would then need a fifth
argument or some special interpretation of LOCAL for that).

martin