all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* We should decouple focus and frame switching
@ 2018-06-10 18:07 Daniel Colascione
  2018-06-10 23:16 ` John Wiegley
  2018-06-11  2:35 ` Eli Zaretskii
  0 siblings, 2 replies; 13+ messages in thread
From: Daniel Colascione @ 2018-06-10 18:07 UTC (permalink / raw)
  To: Emacs developers

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?



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-10 18:07 We should decouple focus and frame switching Daniel Colascione
@ 2018-06-10 23:16 ` John Wiegley
  2018-06-10 23:28   ` dancol
  2018-06-11  2:35 ` Eli Zaretskii
  1 sibling, 1 reply; 13+ messages in thread
From: John Wiegley @ 2018-06-10 23:16 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: Emacs developers

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-10 23:16 ` John Wiegley
@ 2018-06-10 23:28   ` dancol
  2018-06-11  0:04     ` T.V Raman
  2018-06-13  3:34     ` Michael Heerdegen
  0 siblings, 2 replies; 13+ messages in thread
From: dancol @ 2018-06-10 23:28 UTC (permalink / raw)
  To: Daniel Colascione, Emacs developers

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-10 23:28   ` dancol
@ 2018-06-11  0:04     ` T.V Raman
  2018-06-11  0:20       ` dancol
  2018-06-13  3:34     ` Michael Heerdegen
  1 sibling, 1 reply; 13+ messages in thread
From: T.V Raman @ 2018-06-11  0:04 UTC (permalink / raw)
  To: dancol; +Cc: Emacs developers

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

-- 



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-11  0:04     ` T.V Raman
@ 2018-06-11  0:20       ` dancol
  2018-06-11  1:07         ` T.V Raman
                           ` (2 more replies)
  0 siblings, 3 replies; 13+ messages in thread
From: dancol @ 2018-06-11  0:20 UTC (permalink / raw)
  To: T.V Raman; +Cc: dancol, Emacs developers

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-11  0:20       ` dancol
@ 2018-06-11  1:07         ` T.V Raman
  2018-06-11 13:00           ` Clément Pit-Claudel
  2018-06-11 15:17         ` Stefan Monnier
  2018-06-11 15:56         ` Eli Zaretskii
  2 siblings, 1 reply; 13+ messages in thread
From: T.V Raman @ 2018-06-11  1:07 UTC (permalink / raw)
  To: dancol; +Cc: Emacs developers

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

-- 



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-10 18:07 We should decouple focus and frame switching Daniel Colascione
  2018-06-10 23:16 ` John Wiegley
@ 2018-06-11  2:35 ` Eli Zaretskii
  2018-06-11  3:24   ` dancol
  1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2018-06-11  2:35 UTC (permalink / raw)
  To: Daniel Colascione; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-11  2:35 ` Eli Zaretskii
@ 2018-06-11  3:24   ` dancol
  0 siblings, 0 replies; 13+ messages in thread
From: dancol @ 2018-06-11  3:24 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Daniel Colascione, emacs-devel

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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-11  1:07         ` T.V Raman
@ 2018-06-11 13:00           ` Clément Pit-Claudel
  0 siblings, 0 replies; 13+ messages in thread
From: Clément Pit-Claudel @ 2018-06-11 13:00 UTC (permalink / raw)
  To: emacs-devel

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 :)



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-11  0:20       ` dancol
  2018-06-11  1:07         ` T.V Raman
@ 2018-06-11 15:17         ` Stefan Monnier
  2018-06-11 15:56         ` Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Stefan Monnier @ 2018-06-11 15:17 UTC (permalink / raw)
  To: emacs-devel

> 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




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-11  0:20       ` dancol
  2018-06-11  1:07         ` T.V Raman
  2018-06-11 15:17         ` Stefan Monnier
@ 2018-06-11 15:56         ` Eli Zaretskii
  2 siblings, 0 replies; 13+ messages in thread
From: Eli Zaretskii @ 2018-06-11 15:56 UTC (permalink / raw)
  To: dancol; +Cc: emacs-devel, raman

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



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-10 23:28   ` dancol
  2018-06-11  0:04     ` T.V Raman
@ 2018-06-13  3:34     ` Michael Heerdegen
  2018-06-13  3:50       ` dancol
  1 sibling, 1 reply; 13+ messages in thread
From: Michael Heerdegen @ 2018-06-13  3:34 UTC (permalink / raw)
  To: dancol; +Cc: Emacs developers

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.



^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: We should decouple focus and frame switching
  2018-06-13  3:34     ` Michael Heerdegen
@ 2018-06-13  3:50       ` dancol
  0 siblings, 0 replies; 13+ messages in thread
From: dancol @ 2018-06-13  3:50 UTC (permalink / raw)
  To: Michael Heerdegen; +Cc: dancol, Emacs developers

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





^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2018-06-13  3:50 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2018-06-10 18:07 We should decouple focus and frame switching Daniel Colascione
2018-06-10 23:16 ` John Wiegley
2018-06-10 23:28   ` dancol
2018-06-11  0:04     ` T.V Raman
2018-06-11  0:20       ` dancol
2018-06-11  1:07         ` T.V Raman
2018-06-11 13:00           ` Clément Pit-Claudel
2018-06-11 15:17         ` Stefan Monnier
2018-06-11 15:56         ` Eli Zaretskii
2018-06-13  3:34     ` Michael Heerdegen
2018-06-13  3:50       ` dancol
2018-06-11  2:35 ` Eli Zaretskii
2018-06-11  3:24   ` dancol

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.