Re: We should decouple focus and frame switching

[Eli Zaretskii]

> Date: Sun, 10 Jun 2018 17:20:34 -0700
> From: address@hidden
> Cc: address@hidden, Emacs developers <address@hidden>
> 
> 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.

I'd prefer to define a new hook with this new semantics.

Historically, AFAIR the focus-in/out events were used by Emacs
internally for the purposes of switching frames (surprise, surprise).
They were exposed to Lisp relatively recently, and the reason was to
allow us to stop and start the blink-cursor timer, depending on
whether Emacs's frame's were in the foreground.  Then other Lisp
programs started using the hooks, and the rest is history.

Having a new hook that is better suited to Lisp programs will allow us
to encourage migration to it, and perhaps eventually we will be able
to make focus-in/out internal events again, not exposed to Lisp.  And
in the meantime we won't break existing programs which use these
hooks.