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#26513: 25.2; pop-up-frames and *Completions* buffer Date: Sat, 19 Feb 2022 10:40:33 +0100 Message-ID: References: <877d9wpg9z.fsf@gnus.org> <066f0fac-2ce9-fe9a-355f-e148953fc6f0@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="11805"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , "Charles A. Roelli" , 26513@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Feb 19 10:41:34 2022 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 1nLMFC-0002vc-IR for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Feb 2022 10:41:34 +0100 Original-Received: from localhost ([::1]:46686 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nLMFB-0007wa-Ey for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 19 Feb 2022 04:41:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:51282) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nLMEh-0007vg-I1 for bug-gnu-emacs@gnu.org; Sat, 19 Feb 2022 04:41:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:34773) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nLMEg-0007UI-Gc for bug-gnu-emacs@gnu.org; Sat, 19 Feb 2022 04:41:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nLMEg-0000yM-DN for bug-gnu-emacs@gnu.org; Sat, 19 Feb 2022 04:41:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 19 Feb 2022 09:41:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26513 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch confirmed Original-Received: via spool by 26513-submit@debbugs.gnu.org id=B26513.16452636473707 (code B ref 26513); Sat, 19 Feb 2022 09:41:02 +0000 Original-Received: (at 26513) by debbugs.gnu.org; 19 Feb 2022 09:40:47 +0000 Original-Received: from localhost ([127.0.0.1]:56903 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLMEQ-0000xj-O4 for submit@debbugs.gnu.org; Sat, 19 Feb 2022 04:40:46 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:46469) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nLMEP-0000xX-Rk for 26513@debbugs.gnu.org; Sat, 19 Feb 2022 04:40:46 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1645263634; bh=hStGgTlmQrDMBZXBxMULVYPbj/r8Y4T8osJ+Poz/XzA=; h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To; b=b1dn7hhqYNcWOO6NKBVXAdlA/yaUOrAWWtwbQLcVUTIx76RSvmqU+qVpIiIUDhKMz AEEIJQkRUGHtUXomc7WmjSCKADVSMz1oXWqzKFXaPSjYacsnrpywPpY1cJp7l8eJwK GbANykgTq3HG+zRFgeij3vXlyT31LXrao5QBcCHg= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([46.125.249.118]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MS3il-1nont314l1-00TYLO; Sat, 19 Feb 2022 10:40:34 +0100 Content-Language: en-US In-Reply-To: X-Provags-ID: V03:K1:uw7NJ2qz/yzXNiaIxDMSVA6xnSGzOjqipd2ww9H3zKzhEKRbA66 sEEMreIR4VRYzn7gPiCugFWxvBagTh993xi2NYt19gVnRt+kwllGazFQAlVkWB3abIvdRGU Tza85XSRlNWric4lgF7y2dsqmKm3P50bgI3hILphKjNdTax5ZtwIfqFkFrJe890a+yqP7Vn vtGF3PU27IaQ0QlzrA7Pw== X-UI-Out-Filterresults: notjunk:1;V03:K0:VlHsqYGKiL8=:qXfHPSlWLSwygUA9YddnM2 +9kpymzyE7vVbGPMoX36IF1vFJ/3w7NWYdHQ/3hBt0afTfr8FtNdgemcLDKTgp7HLfl5VsiFk fc9XnZBuvDhCBGj02fs2lm0l9RnjuxxjXntmpz4+fFxdlonh5Zl3MDpsD4fsd6fRje2ycB9Bj 0wnndBorTUDWM0/MfLh2G51Y0lvv9Rwt8LEDjfmqBgDCj+Jhx0N0FVWg1HCs42vyd7SHBOUZ8 Hmg4gyCyRvDU1EO0T1J6VNvXS3AsBsrvxp8P629Etsv1yLTYUVenI5d+9tZK6+qRP3Ez6p20E i9hGGDC2po1zCK6xJuf9rdnKITFznCLvSDEPOcCPLN15FLPhocTBiepOJHfmmYEoKbUhXwZla bTFyB/q0JZoDyUCVFqWei+Qlpp8jmToqBYzTItNEVKgYlUfH1+o5VFZgclFK9OQvq3QW/dBca +psjtYPDqN+BXZ/q2+z8Hgn86qqRBjyctXJhsofq6IJ5NpZfaOqvbK/K05nBgDnAktUsnHk3F ZD0D9G8b8rwr2o3b4+CRZcd/QME5St37f8a3/QQn+KOP6t4EdnbY9Xw6RwKTUs3lhCyfJc4L8 su6AEZKzEJ24a/C+Nhow961isYawjsYTu6FTelphV8k/R1ov66FePLu0s7hHD08qZ9gc1GUUb ImcuFpXDKT5PMghcSL21J/4NktHQlhst65xTBOpYC/IV0M0LdpSLvlo34KxPHuWOjkJHbWMGe 6xunI28YBEeVRYcttdvcq1JlyT6P3Ze6bdTxkHT4S6gy6SMhMW0DTKVSrxplLQT/Jkd8sy2U 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:227179 Archived-At: In either case >>> I have a `display-buffer-alist` entry that does all kinds of funny >>> things for *Completions* ;-) >> Please post it here. > > Sorry, top secret. Maybe we really should recommend Drew's package for people setting 'pop-up-frames' to t then. Or does anyone else put *Completions* into a separate frame? > FWIW, my code also uses `redirect-frame-focus` but I agree it's not > a great solution. It's counter-intuitive in the OP's scenario since the *Completions* frame has its own minibuffer window where the dialogue could be continued as soon as that frame gets selected. But here the minibuffer window is not selected. We provide hundreds sorts of completions and I've never been able to understand even one of them. > AFAIK, this all comes down to the fact that when `display-buffer` > creates a new frame, it will all too often end up being selected by the > window manager, even though Emacs doesn't want that window to be the > selected window. > > I sadly don't think we have a good answer for that problem. > I also don't think there's a good reliable way to do that in > general, currently. I suspect what we'd need to do is wait for the new > frame to be "fully" created (not just by us but also on the window > manager side) and when that is settled we should request to focus back > to the frame that had focus before the creation. > > I'm sadly not well enough versed in that kind of GUI code to know how to > do it. And its asynchronous nature makes it worse. Our present weaponry for dealing with this ('no-focus-on-map' or even 'no-accept-focus') is apparently inadequate or was never even tested. The only thing I recall is that waiting for the new frame to get reported (on X it's even never clear which event is responsible for that) and deselecting it afterwards leads to some sort of flickering. martin