We should decouple focus and frame switching

We should decouple focus and frame switching

[Daniel Colascione]

Focus-in and focus-out don't do a good job right now of reflecting 
actual window system focus state, and that's in part due to the core 
considering frame switch evidence of a focus change and running the 
focus-in hooks in response. More than one frame can have window system 
focus at a time when we have multiple terminals, and even on a single 
terminal, internal frame switching for processing mouse wheel events and 
such shouldn't change the reported window system focus state.

How about this? We'll add a frame-focused-p function that returns nil, 
t, or 'unknown, and wire up focus-in-hook and focus-out-hook to run only 
when we actually observe a window system focus change, letting the frame 
switch stuff run completely independently. This way, we'll be able to 
write lisp (as I've been trying to do) that reflects the real window 
system focus.

Sound good?

Re: We should decouple focus and frame switching

[John Wiegley]

>>>>> "DC" == Daniel Colascione <dancol@dancol.org> writes:

DC> How about this? We'll add a frame-focused-p function that returns nil, t,
DC> or 'unknown, and wire up focus-in-hook and focus-out-hook to run only when
DC> we actually observe a window system focus change, letting the frame switch
DC> stuff run completely independently. This way, we'll be able to write lisp
DC> (as I've been trying to do) that reflects the real window system focus.

DC> Sound good?

Why might we not want this?

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: We should decouple focus and frame switching

[dancol]

>>>>>> "DC" == Daniel Colascione <dancol@dancol.org> writes:
>
> DC> How about this? We'll add a frame-focused-p function that returns nil,
> t,
> DC> or 'unknown, and wire up focus-in-hook and focus-out-hook to run only
> when
> DC> we actually observe a window system focus change, letting the frame
> switch
> DC> stuff run completely independently. This way, we'll be able to write
> lisp
> DC> (as I've been trying to do) that reflects the real window system
> focus.
>
> DC> Sound good?
>
> Why might we not want this?

First of all, I'm worried about backward compatibility with existing
packages that rely on the current strange behavior of focus-in and
focus-out. I briefly scanned the tree, ELPA, and EmacsWiki, and I didn't
see anything that would obviously break, but that's no guarantee. The
alternative I was considering is to keep the existing focus events as they
are and add a new set of window-system-focus query functions and hooks
alongside it.

Second, Chesterton's fence: maybe there's a good reason the focus events
are structured the way they are? I was hoping somebody knew why we did it
this way in the first place.

Re: We should decouple focus and frame switching

[T.V Raman]

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 >>>>>>> "DC" == Daniel Colascione <dancol@dancol.org> writes:
>>
>> DC> How about this? We'll add a frame-focused-p function that returns nil,
>> t,
>> DC> or 'unknown, and wire up focus-in-hook and focus-out-hook to run only
>> when
>> DC> we actually observe a window system focus change, letting the frame
>> switch
>> DC> stuff run completely independently. This way, we'll be able to write
>> lisp
>> DC> (as I've been trying to do) that reflects the real window system
>> focus.
>>
>> DC> Sound good?
>>
>> Why might we not want this?
>
> First of all, I'm worried about backward compatibility with existing
> packages that rely on the current strange behavior of focus-in and
> focus-out. I briefly scanned the tree, ELPA, and EmacsWiki, and I didn't
> see anything that would obviously break, but that's no guarantee. The
> alternative I was considering is to keep the existing focus events as they
> are and add a new set of window-system-focus query functions and hooks
> alongside it.
>
> Second, Chesterton's fence: maybe there's a good reason the focus events
> are structured the way they are? I was hoping somebody knew why we did it
> this way in the first place.
>
>

-- 

Re: We should decouple focus and frame switching

[dancol]

> 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.

Re: We should decouple focus and frame switching

[T.V Raman]

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.
>

-- 

Re: We should decouple focus and frame switching

[Clément Pit-Claudel]

On 2018-06-10 21:07, T.V Raman wrote:
> 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.

That's an overstatement. It's broken for some uses, perhaps, but it works mostly fine for other uses.
For example, I have a package that shows a notification when a process completes while emacs is in the background.  This works OK by capturing focus-in and focus-out and toggling a boolean.

This example also sounds like it would be feasible with Daniel's new API, so it sounds pretty good too :)

Re: We should decouple focus and frame switching

[Stefan Monnier]

> 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.

Sounds fair, tho I think this would lose a bit (literally) of
information, so maybe we could call that focus-change-function with
a parameter indicating whether the change is one which increases the
number of frames-with-focus or one which decreases it, since AFAIK we
would have that information when we'd run the hook.

> 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.

Maybe rather than frame-focused-p we should provide a frames-with-focus
function which directly returns the list of frames with focus.

Or a function terminal-frame-focus which returns the terminal's frame
that has focus (or nil), under the assumption that there can only be one
frame with focus in a given terminal.  So instead of looping through
`frame-list`, the Elisp code could loop through `terminal-list`.
It's probably not terribly important, but I often have O(100) frames on
my sole terminal, so the difference is not completely negligible.


        Stefan

Re: We should decouple focus and frame switching

[Eli Zaretskii]

> Date: Sun, 10 Jun 2018 17:20:34 -0700
> From: dancol@dancol.org
> Cc: dancol@dancol.org, Emacs developers <emacs-devel@gnu.org>
> 
> 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.

Re: We should decouple focus and frame switching

[Michael Heerdegen]

dancol@dancol.org writes:

> > Why might we not want this?
>
> First of all, I'm worried about backward compatibility with existing
> packages that rely on the current strange behavior of focus-in and
> focus-out.

FWIW, whenever I quit an Ediff session, I get now with master

| Quit this Ediff session? (y or n) y
| set-frame-parameter: Wrong type argument: frame-live-p, #<dead frame
| Ediff 0x3aafff0>


Michael.

Re: We should decouple focus and frame switching

[dancol]

> dancol@dancol.org writes:
>
>> > Why might we not want this?
>>
>> First of all, I'm worried about backward compatibility with existing
>> packages that rely on the current strange behavior of focus-in and
>> focus-out.
>
> FWIW, whenever I quit an Ediff session, I get now with master
>
> | Quit this Ediff session? (y or n) y
> | set-frame-parameter: Wrong type argument: frame-live-p, #<dead frame
> | Ediff 0x3aafff0>
>
>
> Michael.
>
>

Thanks. I'll take a look.

Re: We should decouple focus and frame switching

[Eli Zaretskii]

> From: Daniel Colascione <dancol@dancol.org>
> Date: Sun, 10 Jun 2018 11:07:09 -0700
> 
> How about this? We'll add a frame-focused-p function that returns nil, 
> t, or 'unknown, and wire up focus-in-hook and focus-out-hook to run only 
> when we actually observe a window system focus change, letting the frame 
> switch stuff run completely independently. This way, we'll be able to 
> write lisp (as I've been trying to do) that reflects the real window 
> system focus.

Does that mean that clicking on a frame will no longer restart cursor
blinking when blink-cursor-mode is in its default configuration?  It
does now.

Re: We should decouple focus and frame switching

[dancol]

>> From: Daniel Colascione <dancol@dancol.org>
>> Date: Sun, 10 Jun 2018 11:07:09 -0700
>>
>> How about this? We'll add a frame-focused-p function that returns nil,
>> t, or 'unknown, and wire up focus-in-hook and focus-out-hook to run only
>> when we actually observe a window system focus change, letting the frame
>> switch stuff run completely independently. This way, we'll be able to
>> write lisp (as I've been trying to do) that reflects the real window
>> system focus.
>
> Does that mean that clicking on a frame will no longer restart cursor
> blinking when blink-cursor-mode is in its default configuration?  It
> does now.

Oh, no. That'll work better than ever. Every time the focus state changes
anywhere, we'll just rescan all the frames and enable the timer if at
least one of them is a focused GUI frame, disabling otherwise. Assuming
all focus events get delivered eventually, the right thing always happens.