[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: We should decouple focus and frame switching

From: T.V Raman
Subject: Re: We should decouple focus and frame switching
Date: Sun, 10 Jun 2018 18:07:44 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

address@hidden 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.>> address@hidden 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]