bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: martin rudalics
Subject: bug#32637: 27.0.50; window-size-change-functions not run from local hook
Date: Wed, 05 Sep 2018 09:47:24 +0200

> 0. In emacs -Q open two windows: one with the *scratch* buffer,
> another window with the *Messages* buffer with e.g. ‘C-h e’
> (view-echo-area-messages).
>
> 1. In *scratch* eval:
>
> (add-hook 'window-size-change-functions
>      (lambda (frame) (message "%S" frame))
>      nil t)
>
> 2. Resize windows with e.g. ‘C-x {’ (shrink-window-horizontally)
>     Check the message with the frame name in *Messages*, fine.
>
> 3. Select the window with *Messages* with ‘C-x o’ (other-window),
>     and resize again ‘C-x }’
>
> No message in *Messages*, because the hook was not called,
> but actually the size of the *scratch* buffer was changed.
>
> window-size-change-functions needs to notify the buffer
> that requested such notifications via this hook.

This is a legitimate request but I'm not sure whether we should do
that for two reasons:

The first reason is that we already run a buffer-local part of
'window-configuration-change-hook' and I dislike it.  Selecting a
window and making its buffer current for the sake of running a hook is
a bad idea IMO because both, selected window and current buffer, are
vital informations and a function run by a hook should be aware of
them.  Worse even, we already make the selected window's buffer
current first which might defeat the expectations of a function run by
the global hook.

Also the window in question might not have changed at all.  The thing
that did change is the window configuration of a frame and it would be
much more interesting if the hook told me what really has changed
instead of telling me that a buffer's window might have changed.

The second reason is a purely technical one: We'd have to walk the
window tree to find out which buffer may have been affected.  However,
the function run by the local hook would still have to find out which
window(s) shouwing the buffer was (were) potentially affected.  This
means that the buffer-local function would have to walk the window
tree a second time anyway.

But I admit that from the application programmer's POV the behavior
you ask for might be convenient, so patches are welcome.  See the code
of run_window_configuration_change_hook in window.c for how to do that
but please do _not_ introduce any side effects when running the global
'window-size-change-functions'.

martin






reply via email to

[Prev in Thread] Current Thread [Next in Thread]