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

[Juri Linkov]

>> > I actually don't understand why we need to support buffer-local hooks
>> > in window-size-change-functions.  This hook clearly applies to the
>> > entire frame, so anything buffer-local sounds inappropriate there.
>> 
>> A buffer-local hook is useful when a mode needs to reformat its
>> buffer content on window resizing.
>
> We have no control on what each hook could or could not do.  We give
> programmers a rope, but cannot prevent them from hanging themselves
> (and take down Emacs with them).
>
> E.g., what happens if two buffers displayed on the same frame have
> different hooks there, which just happen to have conflicting ideas of
> what should be done when windows are resized?  How will they be able
> to reconcile their conflict?

The problem is that currently Emacs entangles programmers with too much rope
for hanging themselves.  See for example how programmers are currently
struggling to emulate buffer-local window-size-change-functions:

  (define-derived-mode bs-mode nil "Buffer-Selection-Menu"
    ...
    (add-hook 'window-size-change-functions 'bs--track-window-changes)
    (add-hook 'kill-buffer-hook 'bs--remove-hooks nil t)
    (add-hook 'change-major-mode-hook 'bs--remove-hooks nil t))

  (defun bs--remove-hooks ()
    "Remove `bs--track-window-changes' and auxiliary hooks."
    (remove-hook 'window-size-change-functions 'bs--track-window-changes)
    ;; Remove itself
    (remove-hook 'kill-buffer-hook 'bs--remove-hooks t)
    (remove-hook 'change-major-mode-hook 'bs--remove-hooks t))

where "Remove itself" indeed sounds like "Hang itself".

We can disentangle programmers from rope to avoid such fragile workarounds
by allowing buffer-local hooks with just

  (define-derived-mode bs-mode nil "Buffer-Selection-Menu"
    ...
    (add-hook 'window-size-change-functions 'bs--track-window-changes nil t))