bug#65217: 29.1; set-frame-size gets confused and drops calls

[Gregory Heytings <gregory@heytings.org>]

>> I'm not sure what you mean by "works correctly".  That exact recipe 
>> (with emacs -Q -l file.el) produces either a 10x10 frame or a 20x20 
>> frame, randomly but apparently equally distributed.  Adding a (sit-for 
>> 0) after the first call to set-frame-size does not help.
>
> Can you check whether input is pending before the 'sit-for' call?
>

input-pending-p invariably returns t in that recipe.

>> But adding a (redisplay t) after the first call to set-frame-size 
>> helps: the result is then always a 20x20 frame.
>
> Here it works with FORCE nil too.
>

Indeed, here it works also with simply (redisplay), with the recipe for 
normal frames.  I guess (redisplay t) is a bit safer though.

>
> (sleep-for 0.001) works here too.  I see problems with (sleep-for 
> 0.00000000000000000000000000000000000000000000000001).
>

(sleep-for 0.001) between the two calls to set-frame-size, in the recipe 
for normal frames, doesn't work here, most often the child frame is 10x10, 
sometimes it is 20x20.  However, (sleep-for 0.001) before the two calls to 
set-frame-size does work, the child frame is always 20x20.

>> One problem remains, however: the message is still either "10 10" or 
>> "20 20".
>
> Always 10x10 wouldn't be that bad.  The "either" means that some race 
> condition persists.  Here I get always "20x20" with the redisplay call.
>

I just tried again to run the recipe for normal frames 20 times in a row: 
I get "10 10" ten times and "20 20" ten times.

>
> My "recipe above" was for normal top-level frames. The patch was for 
> child frames exclusively.  To avoid confusions: The scenario for child 
> frames is
>
> (setq my/frame
>      (make-frame `((left . 500)
>                    (top . 5)
>                    (width . 20)
>                    (height . 20)
>                    (parent-frame . ,(selected-frame)))))
>
> (defun my/twiddle (width height)
>  (set-frame-size my/frame 10 10)
>  (set-frame-size my/frame width height)
>  (sit-for 0)
>  (message (format "%s %s" (frame-width my/frame) (frame-height my/frame))))
>
> (my/twiddle 20 20)
>

The "(parent-frame . ,(selected-frame))" was not in the recipe you sent a 
few hours ago.  Amusingly (or not), with that additional frame parameter, 
the result is always a 10x10 child frame, and the message always "20 20". 
With a (redisplay) or (redisplay t) between the two calls to 
set-frame-size the result is always a 20x20 child frame, and the message 
always "20 20".  With a (sleep-for 0.001) before or between the two calls 
to set-frame-size the result is always a 10x10 child frame, and the 
message always "20 20".

>
> and my patch fixed that here.
>

It also fixes the above recipe, the one for child frames.

>
> The scenario for normal top-level frames is
>
> (setq my/frame
>      (make-frame `((left . 500)
>                    (top . 5)
>                    (width . 20)
>                    (height . 20))))
>
> (defun my/twiddle (width height)
>  (set-frame-size my/frame 10 10)
>  (set-frame-size my/frame width height)
>  (sit-for 0)
>  (message (format "%s %s" (frame-width my/frame) (frame-height my/frame))))
>
> (my/twiddle 20 20)
>
> and my patch doesn't do anything about it.
>

Correct, that's what I also see here.

To summarize:

- with the recipe for normal frames, (redisplay) or (redisplay t) between 
the two calls to set-frame-size, or (sleep-for 0.001) before the two calls 
to set-frame-size, fix the problem (but frame-width and frame-height 
return the actual frame width and height only with a 50% probability)

- with the recipe for child frames, your patch, and (redisplay) or 
(redisplay t) between the two calls to set-frame-size and without your 
patch, fix the problem