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: martin rudalics <rudalics <at> gmx.at>
To: Markus Triska <triska <at> metalevel.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: Wed, 22 Dec 2021 10:22:57 +0100

> 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

Previous Next

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