bug#57012: Activating versus raising frames

[Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

Daniel Colascione <dancol@dancol.org> writes:

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

It does break at runtime when run under X11: just type "C-x h" in a
large file (like xdisp.c), and try to insert the region into another
program with mouse-2.

Other GTK programs run well because simply don't provide the amount of
features that Emacs does.  Their users don't notice various problems
caused by GTK, including "C-S-u" being read as "C-u", or "kp-home" being
translated by the input method into "home".  But our users do, which is
why we do not support X11 on the PGTK builds, since the regular X build
works much better.

It's documented to only support window systems that aren't X11, such as
Wayland and Broadway.

> I don't agree. Telling Emacs that a user has interacted with a frame
> is not an X specific concept.

The point I'm making is that telling Emacs that a user has "interacted"
with a frame should not be necessary at all, and should not be part of
an API exposed anywhere.  Lisp code calls `x-focus-frame'; as a result,
the frame is focused and activated.

Further more, modern window managers are rather notorious for their
draconian "focus stealing prevention", which is probably what we are
running into here.  Kwin and Mutter apparently ignore all
_NET_ACTIVE_WINDOW requests that don't come from a pager when the window
being activated belongs to a program different from that of the
currently active window.

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

Some data being written to an Emacs server socket does not or a timer
calling `focus-frame' does not qualify as "user interaction" and is not
sufficient reason to set the user time.

Timestamp monotonicity does not really matter either, since we are not
dealing with X selections, drag-and-drop or other fancy synchronization
mechanisms.