Re: Window change functions

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> There are several reasons that favor delaying:
>
> (1) When finishing a window excursion by restoring the previous
>     configuration we should run 'window-configuration-change-hook' if
>     and only if something really changed.  Telling whether something
>     really changed is hard and I doubt current Emacs does it right.

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

> (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.

> (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?

> (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.

> 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.

>> Hmm... so to detect when a specific buffer stops being displayed you
>> need to use the global part of the hook and you're not told which was
>> the previously displayed buffer, so you need to keep track of
>> that yourself.
>
> Correct.  The right position to detect when a "specific buffer stops
> being displayed" is (1) 'kill-buffer-hook' and *would be* (2) a
> 'before-delete-window-hook' because right after its deletion a window
> might get GCed immediately and (2) would not have anything else but
> the buffer itself to work upon.  So if someone sees a need for (2)
> please tell me and I'll add such a hook (it won't cost much but some
> lines in the manual).

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).

>> 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.

> He could try it though.

Didn't notice anything funny.


        Stefan