From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Markus Triska Newsgroups: gmane.emacs.bugs Subject: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames Date: Wed, 22 Dec 2021 17:33:09 +0100 Message-ID: <87wnjwr456.fsf@metalevel.at> References: <837dbz2twl.fsf@gnu.org> <84953d3c-e328-6221-3747-f7cfc69d89f6@gmx.at> <87wnjz6spx.fsf@metalevel.at> <058d7891-a08a-2ba8-e3c1-9a29ff3c8092@gmx.at> <87y24fdspi.fsf@metalevel.at> <6faae86d-b1ef-57b4-e5d8-298c7777be24@gmx.at> <87o859vgas.fsf@metalevel.at> <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2999"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: 52666@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 22 17:34:22 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 1n04ZK-0000Wq-Bs for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Dec 2021 17:34:22 +0100 Original-Received: from localhost ([::1]:46568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n04ZI-0004hB-V9 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Dec 2021 11:34:20 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n04Z5-0004gI-9H for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 11:34:07 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48054) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n04Yz-00068e-OM for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 11:34:06 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n04Yz-0001co-L3 for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 11:34:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Markus Triska Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Dec 2021 16:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52666 X-GNU-PR-Package: emacs Original-Received: via spool by 52666-submit@debbugs.gnu.org id=B52666.16401907926187 (code B ref 52666); Wed, 22 Dec 2021 16:34:01 +0000 Original-Received: (at 52666) by debbugs.gnu.org; 22 Dec 2021 16:33:12 +0000 Original-Received: from localhost ([127.0.0.1]:59600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n04YC-0001bj-CW for submit@debbugs.gnu.org; Wed, 22 Dec 2021 11:33:12 -0500 Original-Received: from [78.47.144.35] (port=42068 helo=metalevel.at) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n04YB-0001bb-2f for 52666@debbugs.gnu.org; Wed, 22 Dec 2021 11:33:11 -0500 Original-Received: by metalevel.at (Postfix, from userid 1000) id 62CE29C74E; Wed, 22 Dec 2021 17:33:09 +0100 (CET) In-Reply-To: <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.at> (martin rudalics's message of "Wed, 22 Dec 2021 10:22:57 +0100") 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:222953 Archived-At: martin rudalics writes: > Are you sure that the new frame is _not_ selected when the mouse is _not_ > in that area? Yes, the new frame is *not* selected in that case! I have constructed the following test case to reproduce this: (let ((f (make-frame `((parent-frame . ,(selected-frame)) (left . 200) (width . (text-pixels . 200)) (height . (text-pixels . 200)) (top . 200))))) (eq f (selected-frame))) When I evaluate it, and the mouse is far away from the window, I get "nil" as the result, showing that f is not the selected frame. I get this with the Lucid build on OSX and Debian. In fact, also if the mouse is within the area where the new frame appears, I still get "nil", and the new frame is not selected: The existing frame remains the selected frame, independent of the position of the mouse. I previously thought that the new frame is selected, but that was apparently mistaken: It only appeared to be selected because when entering text, the new (smaller) frame also shows the new text, even though it is entered in the existing frame which is selected. For my specific use case, this behaviour is ideal: I would like to show information in a new frame, but not select the frame. I am surprised to hear that in your configuration, the new frame is indeed selected. Do you accordingly get t as the result of evaluating the above form? Thank you and all the best, Markus