Re: master 4b98a79a50: Improve X event timestamp tracking

[Po Lu]

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.

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

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

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