emacs-devel
[Top][All Lists]
Advanced

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

Re: master 4b98a79a50: Improve X event timestamp tracking


From: Daniel Colascione
Subject: Re: master 4b98a79a50: Improve X event timestamp tracking
Date: Sun, 07 Aug 2022 01:51:36 -0400
User-agent: Evolution 3.44.1-0ubuntu1

On Sun, 2022-08-07 at 08:41 +0300, Eli Zaretskii wrote:
> > From: Daniel Colascione <dancol@dancol.org>
> > Cc: emacs-devel@gnu.org
> > Date: Sun, 07 Aug 2022 00:39:32 -0400
> > 
> > > Consider the following situation: a programmer is writing some
> > > code and
> > > notices that `x-focus-frame' is not working.  But the doc
> > > string says it
> > > should work, without calling magic functions to note "out-of-
> > > band
> > > interaction".
> > > I'm not concerned about how many bytes a terminal hook takes. 
> > > I'm
> > > concerned about exposing a clean abstraction over the window
> > > system
> > to
> > > users and programmers working on display-independent parts of
> > Emacs.
> > 
> > If Emacs, in the background, calls x-focus-frame to activate a
> > window
> > and there's no explicit user intent to activate that window, the
> > WM
> > is within its rights to reject the proposed change to the window
> > stacking. In this case, then the focus stealing mechanism is
> > working
> > at intended. Adding a "no, I really mean it" flag to x-focus-
> > frame
> > would encourage people to break this mechanism by passing that
> > flag
> > whenever x-focus-frame didn't work no matter the reason it didn't
> > work --- even when this function *shouldn't* work because Emacs
> > really is trying to do something that would trigger focus
> > stealing
> > prevent heuristics. 
> > 
> > server.el is a special case: it's okay to break the usual event
> > ordering here because the user *did* interact with Emacs, albeit
> > through a side channel, not the X server. It's not that
> > developers
> > need to call two functions to make some API work, but rather,
> > developers should call an additional function to communicate
> > information to the core that allows an otherwise forbidden-by-
> > design
> > state transition to occur after all.
> > 
> > In other words, the clean abstraction *is* telling Emacs "Oh, by
> > the
> > way, the user interacted with this frame", not telling x-focus-
> > frame
> > "please, actually do your job for some reason". There's nothing
> > X-
> > specific about giving the Emacs core a hint that the user
> > recently
> > interacted with a frame in some manner not reflected in the
> > normal
> > flow of events. If most window systems want to ignore this hint,
> > that's fine, but that doesn't make the hint a leaky abstraction.
> 
> I'm as far from understanding the fine technical details of X
> interaction as it gets, but from the POV of an interested
> bystander,
> it sounds like the practical difference between you two is whether
> in
> the following snippet:
> 
>   --- a/lisp/server.el
>   +++ b/lisp/server.el
>   @@ -1721,7 +1721,9 @@ server-switch-buffer
>               ;; a minibuffer/dedicated-window (if there's no
>   other).
>               (error (pop-to-buffer next-buffer)))))))
>        (when server-raise-frame
>   -      (select-frame-set-input-focus (window-frame)))))
>   +      (let ((frame (window-frame)))
>   +        (frame-note-oob-interaction frame)
>   +        (select-frame-set-input-focus frame)))))
> 
> we should call a special function that Daniel suggests to add, or
> introduce a new optional argument to select-frame-set-input-focus
> to
> force raising the frame, is that right?
> 
> Daniel, you say that adding such a "force" argument will encourage
> Lisp programs to abuse it, but wouldn't they be able to abuse the
> new
> function in the same way?

I think it's important not only to be aware of what developers *can*
do with an API, but of what kinds of solutions the spelling and shape
of that API will guide them towards. Here, I think developers who
want to raise windows in the background contrary to user preference
are more likely to add a "force" flag to their x-focus-window calls 
than to explicitly lie to Emacs about the user having interacted with
a frame when he hasn't --- in the latter case, I think they're more
likely to be aware that they're subverting user intent.

> 
> You also say that the issue is more general than just that of
> raising
> a frame when it gets focus, but do we actually know about other
> situations where that could be an issue?  If we do, then indeed a
> more
> general approach is more beneficial, IMO.

Here's one approach I thought about: while we're executing code in
the context of the server, dynamically bind a variable that select-
frame inspects --- say, select-frame-mark-interacted. When this
variable is true, select-frame (if not NORECORD) would mark each
frame selected in the course of execution as having been "interacted
with" by the user. This way, anything we do on behalf of the user
while executing an action from emacsclient gets counted as user
activity without our having to call (frame-note-oob-interaction
frame) in that (when server-raise-frame ...).








reply via email to

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