From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu Newsgroups: gmane.emacs.devel Subject: Re: master 4b98a79a50: Improve X event timestamp tracking Date: Sun, 07 Aug 2022 13:26:21 +0800 Message-ID: <87h72oy682.fsf@yahoo.com> 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> <75aa6286819b4ca9b008a3697b293567321c0d86.camel@dancol.org> 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="40956"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.91 (gnu/linux) Cc: emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Aug 07 07:27:26 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 1oKYov-000AVh-CQ for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 07:27:25 +0200 Original-Received: from localhost ([::1]:36276 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKYot-0007vN-Os for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 01:27:23 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52118) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKYo9-0007FP-TA for emacs-devel@gnu.org; Sun, 07 Aug 2022 01:26:37 -0400 Original-Received: from sonic317-34.consmr.mail.ne1.yahoo.com ([66.163.184.45]:39808) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oKYo8-0007OR-1Q for emacs-devel@gnu.org; Sun, 07 Aug 2022 01:26:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659849992; bh=DWLXXK8K8/h1HJHCwFcIU7IJAnwg1ziNvK5mn62G7+I=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From:Subject:Reply-To; b=txc/zQXlxNNROwv7ina0YVjPEuQRDyBGADBZYN4/T+s/UQiL5iyhFMJJpD1naP09gEb/dNwkqh4tntSga+75Bsc7ooCC4yx9rGqBy28vzYw23YRlFnxUP64Dg68D63EdckiXqi9PIH8oWObhF76E9zKGT8JOXxb3xx41grngfVhqAFTeIg7KUE1tQdmez7rk6YIwUxyPBfRB8V1Mo1+INQ0cZ4fJeDIkH9JI8emvcwH30/nlphNEXMuw9JJV5eW0iUPuwfikibIXkOL70yR93SHgrebIqWSzANiDsFuYJeV3k682dlV43+kFFwphDeIQzxvZuTJcGigAWqL9SAFpJg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1659849992; bh=XVsZTl45JtDWV4iNLrynGl2lW3bE+ra2I6Z5Ad4VsWE=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=JmwoYCAZo8MTjwDt2Mmcntt0i4cGLlEomAuq/EQHcbrD13PubCxX+SZPQ1Xa7X2Vc2zs78Dv0W1NdJHV/6X/aU2x2MtjIaD1zssz1KbkSM97UfEp7OfHIv+dSHZeJg3FtTspgNM7knMd4omqW8MayrR2DdtuJslF/SSRmEY9DbIMypiITt5G8kvcNEn4vyDcuOY6BOp4tf8xB2SW3wsJJWxj7pDvoFA5/VPyjosZkEFke4pTzgeehAzgXVYBPCpCyKiOJgghTLtLjmTSgPsjkWHbhXl8R0wRlKtw1ps+TJSIj5ZJfEcToh0RRAfI7tWOc++LWiP/5JYphZMsRVBFGA== X-YMail-OSG: tSSt4iwVM1m_e7ZQcE4N3TTOjfisiIOuAhbSfHWXlN.id8o9.9qDePHQ4nY0h5X Qg6.GQQ3l2SnSlkpiL._9nO8anORIoswKWmted1kobuv9DrKZlc8OviLbOsw1N6e8auCTsPDsPu1 kFTKleHgQhaVQ90ZLECfIfXPsTSc4kAZi4C.VJwuSV.W3PAzAap3pJbkAqLR3gfH3HrHSL_2NC69 2nan_PXBwtneUgOOIaLhwrTmlQi_VNgIeAoZQZvS5Nmfxc0RkchM4gUGenvQoTD2BuCgppkPpRNr N020yYs2nVrHLHIjkIVl18S3R4yXenEjtwZTTrKR6pF5t0CdqFML0X292xxCeAygbChKjKY7IW.A T3esC6mbeRmYuBBlOnuRbC5KwZoajxiZ0NKkwSuFCH0fZl86gLj3FM43sjdvBCmhAtSx0xnVLkCB uvDCA2tWE9x5zeI4yzUwl6xM5qwIOSrP2YxmsalCMFZkfOxMd8I4vYOzZ9eGe4DAP75ZcyAsl7K3 EAl0Q9L2qW.2xUBsCbCdjcU1ClI.tYXM69MbKJGTpeJC8zlPlG3m2cp.YGa4b9NIKtB_SE2yBEmV oWDZ9gOMzuVQ4AultA78jqjLzcOoBV7DDvqY5IghM6eOC7osl73BPSUZX.MggquNuu9QJ7zirnSo _B.WD5AJFLwNG68J8CEky0WdfMF1tmFJM4FLrZ29ywwxXmZFt6fUDZzzEHtMgchmDsmh6fqoI8mT ee9fxknsMToOr8tAHbHJGB2lZIRBp8rxg0s7R9SiyGXYOyf4DIlQBgTj5nKCCVbRfe3ibVuMPQRc YTBznj06Qe3Gdd_roVYn5vBVD2yKlViAA4nMaUIN3A X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.ne1.yahoo.com with HTTP; Sun, 7 Aug 2022 05:26:32 +0000 Original-Received: by hermes--canary-production-sg3-6f58cd9b5-pcmsn (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID c67216e371584367299b05416023f695; Sun, 07 Aug 2022 05:26:27 +0000 (UTC) In-Reply-To: <75aa6286819b4ca9b008a3697b293567321c0d86.camel@dancol.org> (Daniel Colascione's message of "Sun, 07 Aug 2022 00:39:32 -0400") X-Mailer: WebService/1.1.20491 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo Received-SPF: pass client-ip=66.163.184.45; envelope-from=luangruo@yahoo.com; helo=sonic317-34.consmr.mail.ne1.yahoo.com 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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:293170 Archived-At: Daniel Colascione writes: > 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 Why would that be so? The window manager doesn't get to decide what the author of some Lisp code wanted. Our users and developers are not sloppy programmers who write code that steals focus from other windows for no reason whatsoever. The intent is demonstrated by code calling x-focus-frame being written. > 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. Why would the activation otherwise be "forbidden-by-design" (_our_ design, not the design of the window manager authors?) Focus stealing prevention doesn't exist on any other platform we support, so x-focus-frame always works there. As such, users expect the same from X. This is compounded by the fact that x-focus-frame says nothing about requiring "user interaction" before the frame is activated. > 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. It is a leaky abstraction because such a hint only exists on X, and was never ever part of Emacs design. Other window systems don't "ignore this hint", because such a hint simply does not exist. > 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? No. Lisp code not a platform implementation detail (be it in server.el or whatever) does not have to know about this at all. > I think an invocation of gnuserver that raiess a window ought to count > as interaction. There are probably other use-cases as well. No, it's not. There is an actual startup notification protocol, but it's not well suited for implementation in emacsclient. > 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. Client events don't include timestamps, so while you can ensure "correct event ordering" with those, you cannot get the server time from them. The actual protocol here is the startup notification protocol, which emacsclient doesn't support for an obvious reason.