bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#57012: Activating versus raising frames


From: Daniel Colascione
Subject: bug#57012: Activating versus raising frames
Date: Sat, 06 Aug 2022 23:11:24 -0400
User-agent: AquaMail/1.38.0 (build: 103800177)



On August 6, 2022 23:03:04 Po Lu <luangruo@yahoo.com> wrote:

Daniel Colascione <dancol@dancol.org> writes:

pgtk also runs on X, and the problem must be solved there in some
manner.

It does not.  We do not support running the PGTK build on X (the
selection code doesn't work on X, for example), and there is no way to
"touch" the user time on that platform without relying on X11-specific
code.  At present, it's not even possible to include gdk/gdkx.h there
due to typedef conflicts with dispextern.h

I'm surprised to hear that considering that many other GTK applications manage selections adequately. If the intent of pgtk is to run only on Wayland, you should break the pgtk build at runtime if it's running under X11, and probably rename it too --- because "pure GTK" sounds like it should rely only on things GTK provides and that it should therefore run anywhere GTK does. If in fact it's just a Wayland window system implementation, call it that.


GTK has no magic facility for knowing that emacsclient
ran. Regardless, a terminal hook is not expensive, and I don't want to
add yet more window system typecases to the code. Terminal access
should be polymorphic. It's through terminal hooks that we make them
polymorphic. I'm not removing the terminal hook.

After thinking a bit, I figure that a better way to solve the problem
would be to document that window managers don't always respect
x-focus-frame, and to add a force parameter which makes it query for the
current server time and set it as the user time, thus making focus
setting more reliable.


I don't agree. Telling Emacs that a user has interacted with a frame is not an X specific concept. And even in the context of X11, we should be resetting the user time generally, not just hacking something up for the special case of x-focus-frame, because 1) the general approach preserves timestamp monotonicity, and 2) the user did in fact interact with the frame.



Thanks.


reply via email to

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