Re: window-buffer-change-functions

[Phil Sainty]

On 2022-09-23 15:19, Richard Stallman wrote:
> A variable is supposed to have one value at any given time.  It might
> be the default binding, or a something-local binding.  But regardless
> of why that binding is current at any time, its value is _the value_
> of the variable at that time.  The other bindings shouldn't affect
> what the variable stands for when they are not current.

Although the case in question is still unusual, it's worth noting that
most hooks might use both the buffer-local and default values when they
run, if both values are defined.  Quoting `add-hook':

    The optional fourth argument, LOCAL, if non-nil, says to modify
    the hook's buffer-local value rather than its global value.
    This makes the hook buffer-local, and it makes t a member of the
    buffer-local value.  That acts as a flag to run the hook
    functions of the global value as well as in the local value.

Therefore, in a majority of cases, running a hook with a buffer-local
value processes both the buffer-local list *and* the global list for
that variable.

As this behaviour is under the control of the buffer-local value,
it's still not the same as both values being used automatically for
two different purposes; but I just wanted to point out that there
has long been an established mechanism by which both the buffer-local
binding and the default binding of a hook variable are used together,
so the window hooks aren't unique in that regard.

The window hooks are different in other ways of course, but they are
reacting to window and frame changes rather than buffer changes, so
it probably wouldn't ever make sense for a buffer-local value to take
precedence over the default value for these hooks.  Splitting each of
them into two separate hooks wouldn't really gain anything in terms
of functionality then?


-Phil