Re: master 4b98a79a50: Improve X event timestamp tracking

[Daniel Colascione]

On August 7, 2022 02:41:25 Po Lu <luangruo@yahoo.com> wrote:

Daniel Colascione <dancol@dancol.org> writes:

Should Emacs set override-redirect all its frames, draw client-side

decorations, and grab the keyboard all the time too --- just in case

the window manager does something wrong? The purpose of a window

manager is to manage windows: it's the part of the system tasked with

what-goes-where policy. I'm genuinely confused about why you think

Emacs in particular should go to lengths to contravene that policy.

Because our users asked for it, and such a policy is causing Emacs bugs.

Like various other places where we fight with the window manager.

Sure, but don't we have, in this instance, an option that doesn't involve fighting the window manager?

This discussion is a great example of why OS developer shouldn't give

application authors an "escape hatch" that lets them opt of policy

enforcement under the theory that they must have some good reason for

doing so. Turns out, everyone thinks he has a good reason.

Fortunately for us, X was designed with a completely different attitude

in mind.

It's definitely from a more naive time. You can tell by the lack of inter-client security.

You're the one suggesting that Emacs developers are somehow talented

enough not to abuse APIs.

Well, your suggestion is also abusing an API, just in a different way.

_NET_WM_USER_TIME only applies to ButtonPress and KeyPress events (and

their input extension equivalents.)  Programs aren't supposed to get the

timestamp from the X server and set the user time, they're only supposed

to do so in response to a limited set of input events.

I'd argue that my suggestion is consistent with the spirit of the API and changes behavior only in a narrow case. Your proposal involves changing the behavior of every x-focus-frame call made when Emacs doesn't have focus, yes? (Also, aren't you worried that the focus check will lead to behavioral inconsistencies?)

Because 1) users won't know it's there, and 2) setting

x-allow-focus-stealing to nil will break the legitimate emacsclient

use-case, and 3) what if every program did this?

It will be documented in PROBLEMS, and emacsclient can be modified to

bind it to some other value in that case.  And Emacs isn't every

program.

It's a preference in some window managers. That it's reached

always-enabled status in others suggests that it's a good thing and a

signaled user preference that Emacs should not attempt to defeat.

So what about everywhere else we bludgeon the window manager into

obeying our commands? Starting from the various frame resizing hacks

(Martin knows more) to actually determining window manager positioning

behavior and fighting with type "A" window managers over the position of

a frame? All of those solutions have worked fine over decades, so I

don't understand why this has to be any different.

Because there's a less invasive alternative.

Yep. That's one way Win32 ends up being better than X.

But then the bug could never be fixed under MS Windows.

The bug doesn't exist on MS Windows because the Win32 API has a function specifically designed to help apps do what emacsclient wants to do.

Emacs is every bit a modern Windows application. There's been a lot of

effort put into graceful degradation when running under

less-than-cutting-edge environments like Windows 95.

I'm talking about the "Modern Application" referred to in the doc,

specifically this part:

* The foreground process is not a Modern Application or the

Start Screen.

Yes it is.

Why, if there's no way to set it?

Sometimes contrary to what the user wants.

Then the user can customize the variable to nil.

Customizing the variable to nil breaks emacsclient.

Yeah, you're right. A synthetic input event would work, wouldn't it?

Synthesizing input events doesn't work either, because the X server will

cargo cult the timestamp you put in the event that's sent.  The only

halfway-reliable way is to change a property on the frame's window and

wait for the PropertyChange event.

(Grabbing the server doesn't work either because the input events that

pile up will get sent first, after the grab is released.)