GNU bug report logs - #52666
27.0.50; Unexpected mode line flickering when creating frames

Previous Next

Full log

View this message in rfc822 format

From: Markus Triska <triska <at> metalevel.at>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 52666 <at> debbugs.gnu.org
Subject: bug#52666: 27.0.50; Unexpected mode line flickering when creating frames
Date: Tue, 21 Dec 2021 21:44:43 +0100

martin rudalics <rudalics <at> gmx.at> writes:

> I later found out that with my GTK-3 build the child frame never became
> visible with your original recipe when I moved the mouse into the area
> reserved for it.  Maybe this is related to my focus follows mouse
> settings maybe it's something else.

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. 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?

> 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. 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.

Thank you and all the best,
Markus

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.