bug#32672: 27.0.50; image resize on window resizing

[martin rudalics]

>>> Your proposed window-state-change-functions would match window-state-get
>>> very well, e.g. it could call the hook with an argument containing alist
>>> of values that really changed, where elements of the alist could have
>>> the same keys as in alist returned from window-state-get,
>>
>> Retaining the nomenclature of 'window-state-get' is part of the plan.
>> But I'm not sure whether we want to retain all of what is recorded in
>> a window state.
...
> Here is a complete implementation that works well when tested
> on display-buffer-directionally in bug#32790

But tying this to the execution of commands misses the point that we
would have to react to state changes whenever a frame is redisplayed.
That is, we would miss all asynchronous, non-command-bound changes in
a frame.

What 'window-state-change-functions' would have to do IMO is:

(1) Record, for each frame, whether window states might have changed
    since the last redisplay of the frame.  That means to set a
    frame's flag whenever the buffer of a window, its selectedness or
    its start point changed.  The reason I'd do this is to avoid the
    costly pre-analysis in (2), for example, after each self-insertion
    or any other change of buffer text.

(2) During redisplay, check whether that flag was set and if so
    compare all windows on that frame with the state recorded during
    last redisplay.  As we do for 'window-size-change-functions'
    already now but also check all window related things like those
    from (1).  If and only if something changed, run the functions on
    'window-state-change-functions' providing them information of what
    has changed - a new window w was made, the buffer of window w has
    changed and b was its buffer during last redisplay, w was selected
    and ww was the window selected during last redisplay and so on.
    Or just give them the old state with, say, window buffers instead
    of window buffer names and the previous and next buffers of each
    window elided (these would be too costly to maintain and analyze,
    I think).  Thereafter, record the new state of the frame and clear
    the flag.

This would improve on the current 'window-configuration-change-hook'
in two regards: We'd run it less often (remember the number of calls
you cited earlier) and we'd run it more accurately (that is, only when
and always when something did really change).

The hard part to code such a thing is _how_ to provide the information
of what has changed.  There are three major elements:

(a) Windows that were added.  Trivial.

(b) Windows that were deleted.  Trivial.

(c) Windows where something changed (size, buffer, start position,
    dedicatedness, a window parameter, 'quit-restore' ???, ...).
    Non-trivial.

Note that not providing that information will mean that the function
run by the hook would have to manually compare the old state with the
present one in order to find out what has changed, much as what they
would do for size changes already now.

> (it doesn't handle
> window-point because then the hook is called too often):

I suppose we could but only when it's written back, that is, changing
point of the buffer shown in the selected window wouldn't count but
writing it back into 'window-point' when selecting another window
would.  But in principle I agree with what you mean here.

martin