bug#32637: 27.0.50; window-size-change-functions not run from local hook

[Juri Linkov <juri@linkov.net>]

> From an application programmer's view the expected behavior of running
> 'window-size-change-functions' buffer-locally would be to call the
> function (1) only if a window displays the buffer now and (2) only if
> the size of that window actually changed.  And it should call the
> function with that window as argument.  Which means that for any
> buffer the function could be called as many times as a window showing
> the buffer has changed its size.  It also means that we don't call the
> function when a buffer has disappeared from the frame.
>
> Now since the argument of 'window-size-change-functions' is the
> associated frame, I agree with Eli that running it buffer-locally
> doesn't make much sense.  The apparent gain in convenience is dwarfed
> by the fact that one would still have to find the window(s) showing
> the buffer.

But in bug#32536 you agreed that Man-window-size-change has to
take care of cases where buffer-local window-size-change-functions
needs to find all Man windows on the frame to compare their sizes
and reformat the buffer with the minimim width from all its windows.

So the window-size-change-functions hook should call the function not
with the window as argument, but with the whole frame, as it already
does now.  And to call the buffer-local hook only once for all
affected windows, as it already does now (the hook has responsibility
to find all its windows from the frame).

> And I still think that running 'window-configuration-change-hook'
> buffer-locally in its current from hardly makes sense either: For
> example, we don't call it for a buffer when that buffer has been
> removed from a window which incidentally is the case that would allow
> Man to remove its function from 'window-configuration-change-hook'.

There is no need to remove function from the buffer-local hook,
because it is called only when the buffer is displayed
in a window.