[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Window change functions
Re: Window change functions
Sat, 05 Jan 2019 01:13:12 -0500
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)
> 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.
- Re: Window change functions,
Stefan Monnier <=
- Re: Window change functions, Stefan Monnier, 2019/01/05
- Re: Window change functions, Eli Zaretskii, 2019/01/05
- Re: Window change functions, martin rudalics, 2019/01/05
- Re: Window change functions, Stefan Monnier, 2019/01/06
- Re: Window change functions, martin rudalics, 2019/01/07
- Re: Window change functions, Stefan Monnier, 2019/01/08
- Re: Window change functions, martin rudalics, 2019/01/09
- Re: Window change functions, martin rudalics, 2019/01/11