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.devel Subject: Re: Stop frames stealing eachothers' minibuffers! Date: Thu, 7 Jan 2021 19:26:02 +0100 Message-ID: <2d91b8cb-0206-32f0-a577-f243fb534aec@gmx.at> References: <20201125210947.GB8228@ACM> <50c96c83-01b4-d2b8-ff90-82c9d706e268@gmx.at> 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="2753"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrii Kolomoiets , emacs-devel@gnu.org, enometh@meer.net, Stefan Monnier , Gregory Heytings , Eli Zaretskii To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jan 07 19:27:39 2021 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 1kxa0Y-0000cm-Jz for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 19:27:38 +0100 Original-Received: from localhost ([::1]:45976 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxa0X-0004ry-L2 for ged-emacs-devel@m.gmane-mx.org; Thu, 07 Jan 2021 13:27:37 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxZzV-0004L2-VT for emacs-devel@gnu.org; Thu, 07 Jan 2021 13:26:33 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:59703) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxZzS-0005N8-Jt; Thu, 07 Jan 2021 13:26:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1610043966; bh=0N4glKoz+8XnC1RJcmVrwPhLPmI4qah8OmqVd/ZilLc=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=XP7lN9487mgp6/UQkC6epQ+NfN2F1VJeBCPcNpwwiUQ/fXRoE9AGELfgMyiTw3G1+ 3a6bMBrhNpw8aL+Dxx+BNVMb+lW0e8QUxaTKvpNHOOkNIt+zCXyZyjNkuzp1MYFUTF Q+4IKxZ/sj8kTVwuPcpd5TI7BrKpus68kgzbUh18= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.100] ([212.95.5.167]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MYNJg-1kSB5A0CHa-00VTU2; Thu, 07 Jan 2021 19:26:06 +0100 In-Reply-To: Content-Language: en-US X-Provags-ID: V03:K1:HqC5g57VN6aFQJI2l9GS2gLYA5wcuoO0+rv3e90HYkBGGVcj2ur sryrXq7pTofHOE9stL5LrOaVROJkd9VnNLIsGe+WGtIVcHcfKEtnVVfV/PQl5NOJA+kTQUr 7eEpUKuemHIrzGSfnSuJ1hdx3Ctj1UXOALY/lzdoMzMd5qIfBBYJXog3G4NlOJ5yZZcqfqj PQNtarYKCo/xrM6sYunDQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:Ex6vXp8D/zk=:xDs0FxsdcKQUmRKvr+IFlg PUcoUuI4oIJmSgwLIgdRZ8jYneJKlAVNtUsL9tj7svXCzDfoUl+wLVjTDHTntMTEchU51tNUp 2HVYNCLgkfXF4shA/2TmznXZkCWGdMqe9mwk/eKKrCNOBLISTifmD/prBpeKBXXZtbh43fChC /Iz+jzlMecDPLfYKHvqZfaLZhzwwhZ5AU06DTHhx35Jm7sm9DP7a9EJVvQCN4yFHYrKA+lI95 64zPSdlj+7pYw25E0hfEA/l3jiaBXwV2taaDrO9eajLyY5zh2vMLAc97VSA9i4qOGn4RExKq1 PnAdV3pvX9eR+WMDJKtOSq3l90CSZ7tV6GHDu3B6fFldXKEmK1Y11IIRbVyEx63Ghud1EK+PN SkRdAnjhoZ9+1eo792OYZ5JEazpF+bWdJymkvh4qpSxDvedl2mgFzEjIkn+ucn/znUhavynih MFX2TnrI+TGCRUVWrrFMLRS/1dZ5Z76zcuCeFg6YgIeJQZFE4rfIKbYGKXDOBWWMfCJ5qB9Xk Lq93czYyT2Fk7HZDSpe8XOVR7m6ANlbM0vaxk0S6gsvKpwSDzX/GyQMv6aBYfdAC+k4CylfQy bdOQhZw719xyRbHeGPjotQoCnaMGNQTYIvL306HZYlzx7JJ3JqMa2/G9q+4fdy5zVolO/5E2k JnnLAkNmsXhXZ9zB803nfUYjsicyBtVlwaAfylBaPkGwTPYq2zaqJOl3kHD9y2bzDUj/vjdot B87/YQUorDxa8vs6KUx1SlfxuqR7x5ITX3toUNDfzfp/HImnF4PQ8Xzqk1WsA59BxqrBrI9K Received-SPF: pass client-ip=212.227.15.18; envelope-from=rudalics@gmx.at; helo=mout.gmx.net X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:262702 Archived-At: > Actualy, I don't think it's as ugly as all that. > select-frame-set-input-focus is an extremely coherent function; it does > one thing and does it well, i.e. switch frames. Maybe it's a pity that > it's a Lisp function rather than a C function, but it is as it is. It does call 'raise-frame' something people with 'focus-follows-mouse' t (not 'auto-raise') might not want here. And it may have to move the mouse cursor according to the 'mouse-autoselect-window' and 'focus-follows-mouse' policies. Most window managers don't handle the latter well (IIRC only the otherwise abominable mutter and KDE could do it approximately). And the former wants the selected window to be set up well before calling 'select-frame-set-input-focus'. > I've been trying to think through the bit about redirect-frame-focus. > It's difficult. Are you aware of any particular scenarios where it might > go wrong with select-frame-set-input-focus? Or is it more a general > concern, possibly from past experience? For example if the source frame > has focus redirected to a MB-only frame, and s-f-s-i-focus is called, > should that redirected focus be undone? I'm a little confused about the > difference between a MB-only frame being the selected frame, and it being > the focus frame of a different "normal" frame. I already had to revert one change because I got that wrong. It's again mostly about using 'focus-follows-mouse' t with a standalone minibuffer frame and I've never been able to understand how people manage that when the normal frame practically completely covers the minibuffer frame. But sooner or later this point will get moot because with Wayland people will be no more able to put a standalone minibuffer frame wherever they want to. >> We're right in hell's kitchen here. > > I've actually implemented the above, on a trial basis. It was actually > surprisingly easy. The C-g bit was just 9 extra lines (plus comments) in > internal_catch (eval.c), and another small function in minibuf.c. > > You say "hell's kitchen". Again, is this on general principles, Just gut feeling. > or can > you see some specific problems which might crop up? My feeling is that > this way of dealing with "not the innermost minibuffer" is simple, and > possibly as good as we're going to get. martin