Re: master 4b98a79a50: Improve X event timestamp tracking

[Eli Zaretskii <eliz@gnu.org>]

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

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.