Re: Window change functions

[martin rudalics]

> I can't remember the last time I found save-window-excursion to be
> useful, so I don't find this use case important.

Taking into account how often it's used in our code base, this use
case is important.  But let's substitute 'set-window-configuration'
for it, or 'window-state-put'.

>> (2) 'balance-windows-area' is a good example for why we should delay
>>      calling size change functions IMO: Its intermediate steps are not
>>      really interesting for any client of that hook.
>
> This is indeed a valid case.  While I do use balance-windows-area, I'm
> not sure how important this is, tho.

It's one example for how many size changes and corresponding calls of
'window-configuration-change-hook' may happen in one and the same
function call.

>> (3) Delaying hooks and running them all in one bunch allows to
>>      reliably look at possibly related changes by consulting the
>>      'window-old-...' functions.
>
> I don't understand this.  If we run the hook right away, the old state
> is easy to get to as well, isn't it?

But after running the hook what would be the "old state"?  I provide
four interrelated hooks and all of them need to know the old state.
Running an arbitrary hook in between would invalidate any consistent
notion of an "old state".

>> (4) Some clients do the delaying themselves by putting an according
>>      function on 'post-command-hook'.  This won't be needed any more
>>      with delayed execution.
>
> The flip side is that while it's currently easy to delay the execution
> using post-command-hook, it will be impossible to *un*delay the
> execution with the new setup.  That's what worries me.

Since the hooks are run after 'post-command-hook' there's indeed no
way to undelay them.  But the effect of running that "something else"
from 'post-command-hook' or from ‘window-configuration-change-hook’
right away should be the same.

>> Note that 'window-size-change-functions' are currently already run
>> right in the middle of redisplay.  Often, window sizes are correct
>> only *after* redisplay.  Think of minibuffer window resizing or
>
> OK, miniwindow resizing is a valid case.

Here I'm not sure though (and Eli was completely sceptical about it).
'window-configuration-change-hook' happily lived decades without
reacting to minibuffer size changes until someone turned up that
stone.  This is one of the areas that must be observed cautiously.

> If we run window-buffer-change-functions eagerly (i.e. from
> set-window-buffer, as well as when creating/deleting a window), then
> it's easy to let the hook access the "old buffer" that's being replaced
> (we can even pass it as a parameter to the hook functions).

But then we would have to run it for every single instance of
'set-window-buffer' or 'with-selected-window'.  The main objective of
the patch was to avoid precisely that (and to not fall into a similar
trap when providing a window selection hook).

>>> IIUC this hook is hence also run for changes to frame-selected-window,
>>> even when that frame is not selected?  I wonder if it's a good idea.
>>> frame-selected-window is a fairly obscure detail, in my experience.
>> If someone changes it separately (that is, sets it for a non-selected
>> frame), there is now a hook to trace that.
>
> Right, and my question is: why bother?  I think it makes the API more
> complex with zero benefit.

Maybe - but why then provide a thing like 'frame-selected-window' in
the first place?

Anyway given the fact that one of our basic invariants is

(eq (selected-window) (frame-selected-window (selected-frame)))

there is also zero cost for the admittedly small benefit.

>> He could try it though.
>
> Didn't notice anything funny.

Thanks for trying.

martin