Re: We should decouple focus and frame switching

["T.V Raman" <raman@google.com>]

dancol@dancol.org writes:

Deprecating focus-in-hook/focus-out-hook is fine by me, I was merely
pointing out that not only are they not used, any usage is hopelessly
broken anyway.>> 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.
>

--