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 22:52:20 -0400 Message-ID: <1827637baa0.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> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="1827637be0e50e228299db4d03" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30679"; 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 04:53:19 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 1oKWPm-0007mP-Mk for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 07 Aug 2022 04:53:19 +0200 Original-Received: from localhost ([::1]:58970 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKWPl-0004MH-7z for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 06 Aug 2022 22:53:17 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38126) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKWPW-0004KG-8Y for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 22:53:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46015) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKWPV-00059r-Tl for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 22:53:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oKWPV-00088a-Lz for bug-gnu-emacs@gnu.org; Sat, 06 Aug 2022 22:53:01 -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 02:53:01 +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.165984074831238 (code B ref 57012); Sun, 07 Aug 2022 02:53:01 +0000 Original-Received: (at 57012) by debbugs.gnu.org; 7 Aug 2022 02:52:28 +0000 Original-Received: from localhost ([127.0.0.1]:35764 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKWOx-00087k-Kl for submit@debbugs.gnu.org; Sat, 06 Aug 2022 22:52:28 -0400 Original-Received: from dancol.org ([96.126.100.184]:51962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oKWOv-00087c-Fs for 57012@debbugs.gnu.org; Sat, 06 Aug 2022 22:52:26 -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=yxW8s3QpHCzD4iwUHfdgevLjiLT2mzJmONw7EPAXm3A=; b=X3JuR0QmVqI45onVlUfQqhRn6Y rt/Fn658Spt/U425TRHOz7hQy0zRgwgL4/kFXfjBsolTOQBm2uR8CVbHvWtrxAiX7sS/mciBHFDm/ U4D8QZO5xqTp9BQ7GqoScwk5ByArRrGWktvZ6p6uSnFLG30KyVS8Ii56pXRsAMxe+vi8VIYf4yw/Z ZnZD5PQVUooyhKL+miiQ1+YDPKUEjBmsf8yMMB++WGtGmxYjtFsZvdqSEategPBfdLdEN37sCPPzR jCBDWobz8MY9uU1KHmzzVwCsc+YKh+JYQ4BpON99jVfEdoETmU5MyfKEvVrhVzcIOVsdCjyoXO+Tg kDwrE4YQ==; Original-Received: from 146.sub-174-212-35.myvzw.com ([174.212.35.146]:10817 helo=[100.107.178.96]) by dancol.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1oKWOt-0006nm-TT; Sat, 06 Aug 2022 19:52:24 -0700 In-Reply-To: <87czdc3h6s.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:239020 Archived-At: This is a multi-part message in MIME format. --1827637be0e50e228299db4d03 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit On August 6, 2022 22:45:26 Po Lu wrote: > Daniel Colascione writes: > >> The GDK code specifically mentions that programs that handle events >> themselves (like Emacs) need to explicitly update the event time (as >> my patch does) > > The GDK documentation is unclear. You only have to update the event > time if the event is not passed to GDK, by setting *finish to > X_EVENT_DROP, which really only happens with key press events. > >> What is the bug? > > Client messages sent to x-dnd.el did not automatically update the user > time, causing various selection-related functions to use an outdated > timestamp. > >> Sorry, but I strongly disagree. The concept of signaling to the >> underlying window system that the user has interacted in some manner >> with a frame is generic and not X-specific. In fact --- doesn't the >> pgtk backend need an implementation of this hook too? It, like the >> conventional GTK backend, is blind to interactions with the frame >> performed using emacsclient. > > No, the PGTK backend doesn't have a concept of "server time". The GDK > Wayland backend implements them via event serials, which cannot be > generated. It is also unnecessary to specify the server time when > trying to activate a toplevel window. > > The only window system I know of that requires that to be specified is > X, so let's keep the code specific to X. pgtk also runs on X, and the problem must be solved there in some manner. 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. --1827637be0e50e228299db4d03 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable


On August 6, 2022 22:45:26 Po Lu <luangruo@yahoo.com&g= t; wrote:

Daniel Colascione <dancol@dancol.org> writes:

The GDK code specifically mentions that programs that han= dle events
themselves (like Emacs) need to explicitly update the eve= nt time (as
my patch does)

The GDK documentation is unclear.  You only have to = update the event
time if the event is not passed to GDK, by setting *finis= h to
X_EVENT_DROP, which really only happens with key press ev= ents.

What is the bug?

Client messages sent to x-dnd.el did not automatically up= date the user
time, causing various selection-related functions to use = an outdated
timestamp.

Sorry, but I strongly disagree. The concept of signaling = to the
underlying window system that the user has interacted in = some manner
with a frame is generic and not X-specific. In fact --- d= oesn't the
pgtk backend need an implementation of this hook too? It,= like the
conventional GTK backend, is blind to interactions with t= he frame
performed using emacsclient.

No, the PGTK backend doesn't have a concept of "server ti= me".  The GDK
Wayland backend implements them via event serials, which = cannot be
generated.  It is also unnecessary to specify the se= rver time when
trying to activate a toplevel window.

The only window system I know of that requires that to be= specified is
X, so let's keep the code specific to X.

pgtk also runs on X, = and the problem must be solved there in some manner. GTK has no magic facil= ity for knowing that emacsclient ran. Regardless, a terminal hook is not ex= pensive, and I don't want to add yet more window system typecases to the co= de. Terminal access should be polymorphic. It's through terminal hooks that= we make them polymorphic. I'm not removing the terminal hook.
--1827637be0e50e228299db4d03--