bug#7381: 24.0.50; Provide a hook run when a window is selected

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>>> Basically, we could keep the old window configuration around from one
>>> "change" to the next but it's not clear whether we want to save the
>>> configuration before the last command or before the last configuration
>>> change.  In the latter case, your code would hardly know whether it runs
>>> within one and the same command or within different commands.
>>>
>>> Note in this context that a single command like setting up a GDB frame
>>> may entail a couple of configuration changes and you would have to keep
>>> track of all of them.  And the hook would trigger within each and every
>>> instance of `with-selected-window' or `save-window-excursion' no matter
>>> how silly these macros are occasionally used.
>>
>> ...and these caveats seem only to confirm such doubts (although some of
>> them would apply to lesser extent to the hypothetical
>> `select-window'-specific hook as well).
>
> I'm afraid they would apply to the same extent.

Hm. Would they? A lot of window configuration changes don't involve
changing the selected window.

>> What's wrong with a separate `window-selected-hook' or perhaps
>> `select-window-hook'?
>
> Nothing but the fact that it might not help you very much.  Your use
> case was formulated in terms of commands
>
>> ... repeating the command would toggle between two windows ...
>
> and not in terms of window selections.  So I don't think that Lennart's
> proposal of using a `post-command-hook' here is unreasonable ;-)

No, my use case is really about the previous selected window (on a given
frame), not specific commands. `select-window' is not even a command.
Checking after each and every command if by any chance we changed the
selected window does seem rather unreasonable to me. I'd much rather
have a `select-window-hook' and keep track of the two last selected
windows.

>> [On a related note, it would be nice if there were some clean and simple
>> way to define custom hooks attached to arbitrary functions; that would
>> solve problems similar to this one, preventing discussions whether adding
>> yet another hook is worth it or not. Something like:
>>
>>   (define-function-hook 'select-window)
>>   => select-window-hook
>>
>>   (add-hook 'select-window-hook ...)
>>
>> Dream on...]
>
> Hooks can be dangerous.  It's very easy to crash Emacs by putting some
> innocuously looking function on `window-configuration-change-hook'.

Well, I don't find that very persuasive. It's not like Emacs lacks other
ways to shoot yourself in the foot, and you can already achieve about
the same (minus the "clean and simple" part) using advice.

> BTW, I could give `get-mru-window' an additional argument like
>
> (defun get-mru-window (&optional all-frames avoid-selected)
>    (let (best-window best-time time)
>     (dolist (window (window-list-1 nil nil all-frames))
>       (setq time (window-use-time window))
>       (unless (and avoid-selected
>                  (eq (window (selected-window))))
>       (when (or (not best-time) (> time best-time))
>         (setq best-time time)
>         (setq best-window window))))
>     best-window))
>
> which would return nil if the selected window is the only one on
> ALL-FRAMES.

That'd be great, yeah (and including it in the trunk).

  Štěpán