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

[martin rudalics]

> 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