From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#50743: Emacsclient not tested vs. Local Variables prompt Date: Mon, 27 Sep 2021 10:50:00 +0200 Message-ID: References: <16835.1632678712@alto> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="37279"; mail-complaints-to="usenet@ciao.gmane.io" Cc: psainty@orcon.net.nz, larsi@gnus.org, 50743@debbugs.gnu.org, jidanni@jidanni.org To: Mike Kupfer , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Sep 27 10:51:42 2021 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 1mUmMP-0009R2-8p for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Sep 2021 10:51:41 +0200 Original-Received: from localhost ([::1]:58532 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mUmMO-0001yN-87 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 27 Sep 2021 04:51:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46516) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mUmLo-0001fm-91 for bug-gnu-emacs@gnu.org; Mon, 27 Sep 2021 04:51:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56315) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mUmLm-0002Y4-8h for bug-gnu-emacs@gnu.org; Mon, 27 Sep 2021 04:51:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mUmLm-0007i8-7H for bug-gnu-emacs@gnu.org; Mon, 27 Sep 2021 04:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 27 Sep 2021 08:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50743 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 50743-submit@debbugs.gnu.org id=B50743.163273262629578 (code B ref 50743); Mon, 27 Sep 2021 08:51:02 +0000 Original-Received: (at 50743) by debbugs.gnu.org; 27 Sep 2021 08:50:26 +0000 Original-Received: from localhost ([127.0.0.1]:39625 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUmLB-0007h0-QN for submit@debbugs.gnu.org; Mon, 27 Sep 2021 04:50:26 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:39769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mUmL9-0007gn-BT for 50743@debbugs.gnu.org; Mon, 27 Sep 2021 04:50:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1632732604; bh=Ne2MHwZyT+VgUBmw635NXq0rA7fS3pFwFqQrgawANPs=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=I/wuqR9qXnNcdQGBP6qnuUBvjcQUkGyhY+8snq4ReFtN/oOfG3UP+lnPhXiJsGYz0 hunTptDWUMW4/tMHtKAH1Kl6n/wnvCJONdCqFh5dJ5tdHPMz/tdSpWidi4kkDiIn9T MsEj6rVzlhAPeo3Bgi5x9pCvbtxSrf+YgLpszpLI= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.5.209]) by mail.gmx.net (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MDQeU-1mfGBO0FWg-00AYcM; Mon, 27 Sep 2021 10:50:04 +0200 In-Reply-To: <16835.1632678712@alto> Content-Language: en-US X-Provags-ID: V03:K1:T0sabGXDkIxpd/hn7adysEhUDeYTnD+vrvyFlRfgzADK/6mQ8gX w3sEdJJ+FTxKPXZuVNczz1oP8oY+AoWNIJAWO7z6dO+b6wBhXZuEWqhwzz0Dtjui0TSLggD OfPApKmUzmmNQl/e9uTG+LFDmSjp4JKVII1PYKzQTf5lcJHQNtbzG9pQ7WaSYstzBn41t49 QKkiF3B6VNXSecU2Tbn/w== X-UI-Out-Filterresults: notjunk:1;V03:K0:5riPL1TQpfM=:7MITJmsspsaSAcuKiTlz3N HeKuwcGhxkZHU7WPUfkhUkpd436imnklHZg8zvN/qQ/xSciyEQznHafdis5NkvYIPn/IivG3x i4b3beL7qi5EjFj+LYGiU+n1JjHtFGxqVONOu/dmlJ0H0JSED/Ng2AjuwfGfLrwzH840o5f8C 4BWIC+Clmrs106r0ShAud/dbdrsRkzzMDvf/sZXVs1YZwDfo1vLPyJNRfSP0N9pTJzMTv6RSK 5XgoUc3hC0Y63ELrIIRF2W0qEcX0pqvGRFTPQCOBN6u56D6wBTRzsaPnI1Rbsr4T0PpeLgF2h E+V8sJIpAzHysbtJZJLrhZTqL7N0Fonzn3FSK62xJpIPrmJvJ3c1VupNjbC0Ab7Vhe17mHZ47 QFnfgnU5D8P5XZW8zXauPGkWFCBugKfTINUTAqoeKR7xYfNhrWm2me3OKfO7r9G/6ClWhqgP5 34C4L+/puYZKBf4TBIt6pj62qRQsVEyIybdypA9UD80xZ2L9Z53RV9bjm1JOhTB11ACp/LxlF R4r8qSVhkmwRFJH346yDpwOFE0udyMuMN1RcTiKbocJX56EyA8vDxRewOv4P8IsGDNeLuQ2dG rC4kGi8kxqDuEPCwAfPbmBdK2Qx/VA2cINPiPCQDgT00tqOvzlQndLn4yauJxBji2QvSB8G+K nPo44jIuWUEV9iOJ6i8Vj5NepiojxskHthJjS5Tjl06F/LYmA3rllSew7S9Bcd9EqKGnIYqHz HKTaruRo3phawuFkTxXzqIS2OgptCrBK9nKz5LFd9dKuz7gorAO69jjYnWn8Bo5Hm356HH3F 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:215643 Archived-At: > Still, if I have "focus stealing prevention" set to None, the Emacs > frame is raised in both the prompting case and the non-prompting case, > but the input focus is handled differently in the two cases. Raising > the frame but not getting the input focus doesn't seem right to me. "Focus stealing" is not a well-defined behavior and "preventing" it is even less so. It may depend on whether the focus-stealing window was formerly nonexistent, invisible or iconified and/or whether the window stems from the same application, executable or process. Focus may also depend on whether mouse movement can determine which window gets focus and whether that window should be raised too when it gets focus. All this is additionally complicated by the fact that there are no APIs an application can use to tell which policy has been set up to decide how it should behave. But in general, any application's focus stealing behavior has been set up by the user - compliantly or intentionally. In particular, we all agree that Emacs may steal focus from itself since otherwise popping up a second frame would never allow that frame to get focus immediately. But we probably are not sure whether running a timer or reacting to a file notification should make Emacs pop up a new frame and give it focus - the policy here will depend on the case at hand. Note also that desktop managers like GNOME shell do not show a taskbar any more, so they cannot even pulse the icon of the application requesting focus there as, for example, Windows usually does in such case. Finally, Wayland seems to ignore requests to transfer focus in any case. So applications may have to change their attitude wrt newer backends, desktops and user behaviors in order to not fall behind or even be regarded as hostile. That said, I agree with Mike when he says that "Raising the frame but not getting the input focus doesn't seem right to me". Emacs should try its best to to not drive the user into such a situation. martin