From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: master 4b98a79a50: Improve X event timestamp tracking Date: Sun, 07 Aug 2022 08:41:30 +0300 Message-ID: <83pmhcy5it.fsf@gnu.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> <75aa6286819b4ca9b008a3697b293567321c0d86.camel@dancol.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32106"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 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:43: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 1oKZ4f-0008D9-66 for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 07:43:41 +0200 Original-Received: from localhost ([::1]:39040 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oKZ4d-00025g-Ld for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Aug 2022 01:43:39 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53834) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZ2r-0001Mp-FK for emacs-devel@gnu.org; Sun, 07 Aug 2022 01:41:49 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:49516) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZ2q-0000fO-MT; Sun, 07 Aug 2022 01:41:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=6bX1payC2caLreEgsPAMXuiXFH0Nja74Cq4Njhf/LyY=; b=hZioh7p/nJTxqu0r/pEl DNaKMy3CtvlvR9ovpgLdbHJjHXvvAXqChgI9oPnKfcGYOAHaTjjWgQnAMcqbyHrml6GjGIR2UGjZm cKQM0SIc6Gqt2t5x2nxsyvlmjzegezBRTb8/o3EKvT/LZNnsQPsY1E5QiMEPWS4wibF0YsJWeagQ/ zGBhoaKpI7ZqbQlHWekbUa4a3O4EOaftmy3EvyNCMVp1WyqJut6NJ5I0N8PPZgPycTQsd080ZquhC /AorCs7yfLY9TefWbIlcjOoTsOHIqUzxCuWvLLB8/f0QJnPhzxmHXb3GzFWcdCPNJgL6mu68u5GG1 lDPepO5dUwMauQ==; Original-Received: from [87.69.77.57] (port=1361 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oKZ2q-0005v1-4K; Sun, 07 Aug 2022 01:41:48 -0400 In-Reply-To: <75aa6286819b4ca9b008a3697b293567321c0d86.camel@dancol.org> (message from Daniel Colascione on Sun, 07 Aug 2022 00:39:32 -0400) 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:293171 Archived-At: > From: Daniel Colascione > Cc: emacs-devel@gnu.org > Date: Sun, 07 Aug 2022 00:39:32 -0400 > > > 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. > > server.el is a special case: it'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. I'm as far from understanding the fine technical details of X interaction as it gets, but from the POV of an interested bystander, it sounds like the practical difference between you two is whether in the following snippet: --- a/lisp/server.el +++ b/lisp/server.el @@ -1721,7 +1721,9 @@ server-switch-buffer ;; a minibuffer/dedicated-window (if there's no other). (error (pop-to-buffer next-buffer))))))) (when server-raise-frame - (select-frame-set-input-focus (window-frame))))) + (let ((frame (window-frame))) + (frame-note-oob-interaction frame) + (select-frame-set-input-focus frame))))) we should call a special function that Daniel suggests to add, or introduce a new optional argument to select-frame-set-input-focus to force raising the frame, is that right? Daniel, you say that adding such a "force" argument will encourage Lisp programs to abuse it, but wouldn't they be able to abuse the new function in the same way? You also say that the issue is more general than just that of raising a frame when it gets focus, but do we actually know about other situations where that could be an issue? If we do, then indeed a more general approach is more beneficial, IMO.