Re: master 4b98a79a50: Improve X event timestamp tracking

[Daniel Colascione <dancol@dancol.org>]

On Sun, 2022-08-07 at 12:23 +0800, Po Lu wrote:
> Daniel Colascione <dancol@dancol.org> writes:
> 
> > I've contributed code all over this project and never been limited by
> > MAINTAINERS. This file does not grant you the authority to
> > arbitrarily reject contributions that fix long-standing bugs. You're
> > welcome to make improvements to committed code just like anyone else.
> > I'd suggest minimizing friction in the future, not blocking useful
> > work form someone who spent all day debugging this issue.
> 
> I have not arbitrarily rejected anything.  I've told you why this isn't
> a good idea, yet you proceeded to install the change anyway.  Please, no
> rush!
> 
> > An "entire terminal hook" is a trivial function pointer.
> > Don't you think this is a mountain out of a molehill? What,
> > precisely, is the resource being consumed by minimizing terminal hook
> > structure fields?
> 
> 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.

> 
> > Sure, we could have open-coded typecases or inscrutably invocations
> > of some "force" parameter --- or we could make a generic terminal
> > operation that clearly and explicitly expresses user intent. It's not
> > as if the X event timestamp mechanism exists without reason either.
> 
> The X server clock exists to provide orderly synchronization of input
> focus and selection ownership.  Ensuring Emacs works with that
> synchronization isn't the job of Lisp code in server.el or C code in
> termhooks.h, it's the job of C code in x*.c.

Don't you think it is the job of server.el to tell that window system
core code a fact that it wouldn't have otherwise known --- that the
user interacted with the frame in some manner the window system
wouldn't have otherwise know about? I think an invocation of
gnuserver that raiess a window ought to count as interaction. There
are probably other use-cases as well.

> 
> > Focus-stealing prevent isn't some "draconian" measure to work around
> > or a bug in window managers, but instead a way to properly order
> > events observed in a distributed, asynchronous system.
> 
> Focus stealing prevention is a draconian measure to ensure that programs
> in the background do not suddenly move themselves into the foreground.
> 
> Which works, until it doesn't, like with the Emacs server.

Yes. Ideally, we'd detect in emacsclient that emacsclient and emacs
were running on the same X server and transmit the command buffer as
a ClientEvent --- and we'd update our user timestamp when we got that
event, giving us a globally correct event ordering. In the meantime,
the "user interacted out of band" hint seems like the most
conservative approach for working around focus stealing mitigations.

> 
> > You're proposing scrapping a generic mechanism and replacing it with
> > a special case, and I don't right now see the net benefit.
> 
> Because that generic mechanism exposes low-level window system
> implementation details to users.  The Lisp programmer shouldn't need to
> know he must call two functions, instead of one, to ensure that
> x-focus-frame results in a frame being activated, which defeats the
> whole point of Emacs abstracting over the window system.