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.devel Subject: Re: master 4b98a79a50: Improve X event timestamp tracking Date: Sun, 07 Aug 2022 00:39:32 -0400 Message-ID: <75aa6286819b4ca9b008a3697b293567321c0d86.camel@dancol.org> References: <165984385935.14715.8191942019361575877@vcs2.savannah.gnu.org> <20220807034419.B5F2FC09BFD@vcs2.savannah.gnu.org> <87y1w0zpe9.fsf@yahoo.com> <87r11szp6h.fsf@yahoo.com> <19d020d85bed5d030e706800f8cbb0b7fbb3bc65.camel@dancol.org> <875yj4znp5.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="29212"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.44.1-0ubuntu1 Cc: emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 07 06:42:41 2022 Return-path: Envelope-to: ged-emacs-devel@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 1oKY7c-0007Qn-EX for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 06:42:41 +0200 Original-Received: from localhost ([::1]:59432 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKY7a-0002Oj-R6 for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 00:42:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46994) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKY4h-0001Y4-9i for emacs-devel@gnu.org; Sun, 07 Aug 2022 00:39:39 -0400 Original-Received: from dancol.org ([2600:3c01:e000:3d8::1]:42296) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKY4e-0001Vi-Qb for emacs-devel@gnu.org; Sun, 07 Aug 2022 00:39:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:Cc:To:From:Subject:Message-ID:Sender:Reply-To: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=9imP9Zc8irQ+9V1gOB/ugWDdEZZz9ZtgGuIFwsFhgXQ=; b=HYmK5+4tNnt001WyiQkKo9PPhk KtkmepsJbLr9G6oQmetnthNgzHEIIAYENNNEM+keTnp7pdXKFzYuQMWX9tHdQp+Uhg17DhI+bPxCJ 9b2IcMh/hUwNnbSNISSlZfRp6FVumQZNgsXpq/lkfJVoL+4BaeFZl1ufmbDYb7LwglgcJH78LGvTe 4PM2aWwYB+9cWUdDcCB0oFFCA3v4+Jt0ka5PVlM+vC5iHxZ6XsTaiMuYkz9EDhKHw19BgHmLZgwiC PNmxSIW46Kknj/8PdeJ71pnn5NgU5N5+X+lAVts6vZ40jONXsyIWYVyqkbbOB2VFftaxyfXI/vheW as4zcESA==; Original-Received: from 2603-9001-4203-1ab2-8089-fae0-ee36-06a4.inf6.spectrum.com ([2603:9001:4203:1ab2:8089:fae0:ee36:6a4]:49728) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1oKY4c-0006xR-4T; Sat, 06 Aug 2022 21:39:34 -0700 In-Reply-To: <875yj4znp5.fsf@yahoo.com> Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@dancol.org; helo=dancol.org X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:293169 Archived-At: On Sun, 2022-08-07 at 12:23 +0800, Po Lu wrote: > Daniel Colascione writes: >=20 > > I've contributed code all over this project and never been limited by > > MAINTAINERS. This file does not grant you the authority to > > arbitrarily reject contributions that fix long-standing bugs. You're > > welcome to make improvements to committed code just like anyone else. > > I'd suggest minimizing friction in the future, not blocking useful > > work form someone who spent all day debugging this issue. >=20 > I have not arbitrarily rejected anything. I've told you why this isn't > a good idea, yet you proceeded to install the change anyway. Please, no > rush! >=20 > > An "entire terminal hook" is a trivial function pointer. > > Don't you think this is a mountain out of a molehill? What, > > precisely, is the resource being consumed by minimizing terminal hook > > structure fields? >=20 > Consider the following situation: a programmer is writing some code and > notices that `x-focus-frame' is not working. But the doc string says it > should work, without calling magic functions to note "out-of-band > interaction". > I'm not concerned about how many bytes a terminal hook takes. I'm > concerned about exposing a clean abstraction over the window system to > users and programmers working on display-independent parts of Emacs. If Emacs, in the background, calls x-focus-frame to activate a window and there's no explicit user intent to activate that window, the WM is within its rights to reject the proposed change to the window stacking. In this case, then the focus stealing mechanism is working at intended. Adding a "no, I really mean it" flag to x-focus-frame would encourage people to break this mechanism by passing that flag whenever x-focus-frame didn't work no matter the reason it didn't work --- even when this function *shouldn't* work because Emacs really is trying to do something that would trigger focus stealing prevent heuristics.=20 server.el is a special case:=C2=A0it's okay to break the usual event ordering here because the user *did* interact with Emacs, albeit through a side channel, not the X server. It's not that developers need to call two functions to make some API work, but rather, developers should call an additional function to communicate information to the core that allows an otherwise forbidden-by-design state transition to occur after all. In other words, the clean abstraction *is* telling Emacs "Oh, by the way, the user interacted with this frame", not telling x-focus-frame "please, actually do your job for some reason". There's nothing X- specific about giving the Emacs core a hint that the user recently interacted with a frame in some manner not reflected in the normal flow of events. If most window systems want to ignore this hint, that's fine, but that doesn't make the hint a leaky abstraction. >=20 > > Sure, we could have open-coded typecases or inscrutably invocations > > of some "force" parameter --- or we could make a generic terminal > > operation that clearly and explicitly expresses user intent. It's not > > as if the X event timestamp mechanism exists without reason either. >=20 > The X server clock exists to provide orderly synchronization of input > focus and selection ownership. Ensuring Emacs works with that > synchronization isn't the job of Lisp code in server.el or C code in > termhooks.h, it's the job of C code in x*.c. Don't you think it is the job of server.el to tell that window system core code a fact that it wouldn't have otherwise known --- that the user interacted with the frame in some manner the window system wouldn't have otherwise know about? I think an invocation of gnuserver that raiess a window ought to count as interaction. There are probably other use-cases as well. >=20 > > Focus-stealing prevent isn't some "draconian" measure to work around > > or a bug in window managers, but instead a way to properly order > > events observed in a distributed, asynchronous system. >=20 > Focus stealing prevention is a draconian measure to ensure that programs > in the background do not suddenly move themselves into the foreground. >=20 > Which works, until it doesn't, like with the Emacs server. Yes. Ideally, we'd detect in emacsclient that emacsclient and emacs were running on the same X server and transmit the command buffer as a ClientEvent --- and we'd update our user timestamp when we got that event, giving us a globally correct event ordering. In the meantime, the "user interacted out of band" hint seems like the most conservative approach for working around focus stealing mitigations. >=20 > > You're proposing scrapping a generic mechanism and replacing it with > > a special case, and I don't right now see the net benefit. >=20 > Because that generic mechanism exposes low-level window system > implementation details to users. The Lisp programmer shouldn't need to > know he must call two functions, instead of one, to ensure that > x-focus-frame results in a frame being activated, which defeats the > whole point of Emacs abstracting over the window system.