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#52666: 27.0.50; Unexpected mode line flickering when creating frames Date: Wed, 22 Dec 2021 10:22:57 +0100 Message-ID: <1557a1b7-f634-3add-5dde-6326b0b74328@gmx.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> 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="29044"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52666@debbugs.gnu.org To: Markus Triska Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 22 10:24:13 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 1mzxr2-0007JN-QM for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Dec 2021 10:24:12 +0100 Original-Received: from localhost ([::1]:60014 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mzxr1-00022r-Qn for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Dec 2021 04:24:11 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:44762) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mzxqs-0001zH-Uo for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 04:24:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45256) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mzxqs-0002Q8-KH for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 04:24:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mzxqs-0005mP-Gt for bug-gnu-emacs@gnu.org; Wed, 22 Dec 2021 04:24: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: Wed, 22 Dec 2021 09:24:02 +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.164016498822120 (code B ref 52666); Wed, 22 Dec 2021 09:24:02 +0000 Original-Received: (at 52666) by debbugs.gnu.org; 22 Dec 2021 09:23:08 +0000 Original-Received: from localhost ([127.0.0.1]:56798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzxpz-0005ki-NG for submit@debbugs.gnu.org; Wed, 22 Dec 2021 04:23:07 -0500 Original-Received: from mout.gmx.net ([212.227.15.18]:37175) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mzxpx-0005jz-L4 for 52666@debbugs.gnu.org; Wed, 22 Dec 2021 04:23:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1640164979; bh=HSkhajexnSa0ABFt7fqV0CsNNdUt0V6Sdr4JXlOxHdQ=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=VV49P1q+0qxGJ0T1e6cNwcZEianLgJR8e/kglhVcwr8j4mnriUkG4va1/DXFgR2Uw hIEad06CGjkgvOEaCDTn2dzD5q/XO+J5ZLoNY+TL8aD6Yz87ViTrM9kMZULEHtqY0r SGTyymCwJ6NNafJAnw46T7bQ/bJ3dff8XYIuvCb0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.102] ([212.95.5.187]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MGhuK-1nCasC39PO-00Dp3d; Wed, 22 Dec 2021 10:22:58 +0100 In-Reply-To: <87o859vgas.fsf@metalevel.at> Content-Language: en-US X-Provags-ID: V03:K1:v+3PQxRI2oqIq4i38CUhdFr1ii0R9ZygpiVG8+UBIe7vLrlfzHG K4X/qFUIqX4N0LoMB3Po5ncItajcCwxfa5iluLaHntyEhZgIpEf29+KrSu9dK0wbFQlHcdB BCYk2bnoQlyR1Sm+NUmUcoHDsQc9GCwcXg5xeu3c6VPZpwOzsIwX4NKH95YFRnmUiOmkQtI kWnqLy+wD7oRL8rZckHGQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:O5B8H2Fjjf0=:egSMLqtgzCg/cB8WzrcgBe PB5ZXn9sHtLOYQ5fh4iCe3ErOTLID8Oo0pO6Ciyw9gyq3snueqwkWploOfgM+0UHRbLqDU0Fs Eflm/ZnoIOGvnGHQ+pNYHpTa6j47Q9uwfw/f5CnqlSD7X73qTydRHBmVF8fOcRNG5qYGqryVj UkMkrS03pUxbeHXS8BrSkCHC54Ep47owhTVkJlOMx7O5+lP4TBLkliFaoXz8X0Q9GsMWJI5D+ ipegcCrUppWzDK6KwrUYfGxurdbolQYHHnCa63ZXVdRQw8HOu1wyYgIBW9gYEF0XGq72pJ/fM QnxEqmN6LUFs88kcCSsvHsed1mU6B13MFxMTneq/EKdN1/7Eha3bB11xPOn/yX+NYfYB8F9JL pirm4uaznLE0FmD2rz4rBGFLThsbXrYIHKM/G4GaYL6xLWXY+ltm1QKOjtFJFvuyLsFqT8eId uN5BNHeU/lbAFXaAeR3bXsPd43YQcaFnB9izSBliJJUARyFDYM5n14TnuJQOesCa4pbDAiFla FO1EAAyflc5cI60OS4o8hrWAT0XCUFlxBoE3x4E94l2vJwi0hj+SOr9XTRTgxGLv6BuaNZrVd TbBNrLQ0vle+yFdCSalSKRjgEIUFJ6JQwgAHWMhw0az7TnsoytG7NDg/7C5PDR7i0tpV22wpZ Pn9IeCx7xVC3n9b34uMkGfFvpFQmWonknFTTm2zH4d4WOC5ezF0pBufJECXkspN866/wCERAA hRkNpgE1Ez4DuG+ISdKnBZA2phW05NW8o6XX5engMQw8klj7YGEG5p+nfqTXWMvMxIXKR3Nx 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:222920 Archived-At: > I also noticed this: When the mouse is in the area where the new frame > arises, then the new frame is selected on all platforms I tried. Are you sure that the new frame is _not_ selected when the mouse is _not_ in that area? > I have > set focus-follows-mouse to nil (the default). Ideally, I would like the > existing frame to reliably retain the focus, and the new frame to not be > selected when it is created. Is there any way to reliably ensure this? Not in my experience. Conceptually, it should be possible by setting the 'no-focus-on-map' or temporarily (that is until the frame has become visible) the 'no-accept-focus' window parameter but I haven't yet seen a WM strictly adhering to that discipline. It worked best on Windows XP. >> corner of the parent's native frame. Since the size of the child frame >> is by default that of its parent, the child frame will thus draw over >> the entire area of the parent frame (including mode line and scroll > > I think this is the part that can be counterintuitive, since the Elisp > documentation states: > > 39.2 Forcing Redisplay > ====================== > > Emacs normally tries to redisplay the screen whenever it waits for > input. > > In the example that exhibits the flickering, there is no waiting for > input between the creation of the frame and the change of its width and > height. Maybe that line is confusing. Emacs may have to redisplay whenever it receives a corresponding event (like Map, Visibility, Expose and Focus notifications). Waiting for user input is only a tangential aspect there. What that chapter tries to describe is that an application can try to force additional redisplays by using the means described there. Inhibiting redisplay (via setting 'inhibit-redisplay') is in general not supported and might have no effect either. > Therefore, it is unexpected that the frame is drawn over the > entire area of the parent frame. I expected it to be drawn only for the > area it is configured, when Emacs waits for input. Emacs does not necessarily "wait for input" in that case. Depending on the underlying windowing system it might rather wait for a MapNotify or ConfigureNotify event. martin