Re: We should decouple focus and frame switching

[dancol@dancol.org]

> dancol@dancol.org writes:
>
> focus-in-hook and focus-out-hook are demonstrably broken --- I remember
> sending a message here that showed those hooks firing multiple times
> under stumpwm for a single window-switch event. I believe someone else
> also reproed the buggy behavior under a different WM

Yeah. That said, I'm not sure that asking for strictly ordered
exactly-once delivery is reasonable where we have a bunch of asynchronous
window systems and now focus events also being delivered to TTY terminals
via escape codes. Suppose you're switching from a TTY gui frame to a GUI
frame: you might see the focus-in on the GUI frame before the focus-out on
the TTY, and there's nothing we can do about it. Or it could happen the
other way around, unpredictably.

I don't even think we should have separate focus-in and focus-out hooks.
We should just have one extension point, some kind focus-change-function.
Modes would add-function a handler to focus-change-function, and each time
the handler is called, it'd re-scan all the frames and windows it's
interested in and do whatever it wants to do based on that snapshot of the
current focus state. That's why it's important to provide some kind of API
that lets a package ask Emacs, "To the best of your current knowledge,
does FRAME have input focus?" and not just rely on state change
notifications.

Now, we already have focus-in-hook and focus-out-hook. Do we just apply
the new semantics to these hooks? Having two separate hooks encourages
people to use the fragile edge-triggered model instead of the
level-triggered one I described above.

Maybe the right approach is to just declare focus-in-hook and
focus-out-hook obsolete and not call them anymore at all, then direct
people to this new focus-change-function extension point that has the
improved semantics I described. I normally don't like that sort of change,
but the existing hooks are hopelessly broken.