From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.bugs Subject: bug#57012: Activating versus raising frames Date: Sat, 06 Aug 2022 23:11:24 -0400 Message-ID: <18276492f60.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> References: <18270a59cb0.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <878ro25eo7.fsf@yahoo.com> <6c3817726a4fc63e83a3d004dffdf072cae278c5.camel@dancol.org> <87y1w03jhv.fsf@yahoo.com> <06468240-fd7c-72e8-2538-b65dd2f28665@dancol.org> <87czdc3h6s.fsf@yahoo.com> <1827637baa0.2829.cc5b3318d7e9908e2c46732289705cb0@dancol.org> <87pmhc21t3.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="1827649312950e22829942815c" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33996"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: AquaMail/1.38.0 (build: 103800177) Cc: 57012@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Aug 07 05:12:24 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oKWiF-0008bF-D0 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Aug 2022 05:12:24 +0200 Original-Received: from localhost ([::1]:60216 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKWiD-00068i-Km for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Aug 2022 23:12:21 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:39242) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKWhx-00068Z-FZ for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 23:12:05 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46025) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKWhu-0007Dk-NT for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 23:12:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oKWhu-00009t-EP for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 23:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Colascione Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Aug 2022 03:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57012 X-GNU-PR-Package: emacs Original-Received: via spool by 57012-submit@debbugs.gnu.org id=B57012.1659841892567 (code B ref 57012); Sun, 07 Aug 2022 03:12:02 +0000 Original-Received: (at 57012) by debbugs.gnu.org; 7 Aug 2022 03:11:32 +0000 Original-Received: from localhost ([127.0.0.1]:35774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKWhP-000094-Q0 for submit@debbugs.gnu.org; Sat, 06 Aug 2022 23:11:32 -0400 Original-Received: from dancol.org ([96.126.100.184]:51964) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKWhM-00008t-2V for 57012@debbugs.gnu.org; Sat, 06 Aug 2022 23:11:30 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:MIME-Version:Subject:References:In-Reply-To:Message-ID: Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=VVk60tR/25H7xrpv94AikALew0kb/dXgRxHzu+xGioc=; b=WSSS+KwL+q1hppOKjdDi7pZhdj swW2lQ5pNFYu0h8Kq5j8cVQFnKL2ZAgoiDZTjR9ItKYJ9ApJV/hB5jg4OcJL73d5Jf59fxafetWBs XZ3SAClu9/TMJ1AOPz/A5aRCJ4R+oyLmOa4TcgHAzCfMhGerSMDzlq7Q9GLxQ9Tysl9IU3NilIfle w+tYCdRNCxaYoQOWmt0LwpoZetV4LtcV/2E1fv/5kl/a36Wm7JFRqNiBCc2tVl6zUndNucu/uWC9g CITpR92nFt6bbD9CMqE/ooqXxyjKnSBhIeNFxxQAftZat+F5wjeNB5njXF9HcnTvO+hpyUJI18BVD ZxlQA/xA==; Original-Received: from [97.104.88.154] (port=41478 helo=[192.168.86.77]) by dancol.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1oKWhK-0006pW-Hz; Sat, 06 Aug 2022 20:11:26 -0700 In-Reply-To: <87pmhc21t3.fsf@yahoo.com> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:239022 Archived-At: This is a multi-part message in MIME format. --1827649312950e22829942815c Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit On August 6, 2022 23:03:04 Po Lu wrote: > Daniel Colascione 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. --1827649312950e22829942815c Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


On August 6, 2022 23:03:04 Po Lu <luangruo@yahoo.com&g= t; 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 bui= ld 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 he= ar that considering that many other GTK applications manage selections adeq= uately. If the intent of pgtk is to run only on Wayland, you should break t= he 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 pr= ovides 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. Termina= l access
should be polymorphic. It's through terminal hooks that w= e 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 re= spect
x-focus-frame, and to add a force parameter which makes i= t query for the
current server time and set it as the user time, thus mak= ing focus
setting more reliable.


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



Thanks.

--1827649312950e22829942815c--