bug#52666: 27.0.50; Unexpected mode line flickering when creating frames

[martin rudalics <rudalics@gmx.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