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

[Gregory Heytings <gregory@heytings.org>]

>
> Does that mean that my older recipe
>
> (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)
>
> works correctly with your setup?
>

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.  But adding a (redisplay 
t) after the first call to set-frame-size helps: the result is then always 
a 20x20 frame.

One problem remains, however: the message is still either "10 10" or "20 
20".

>
> In which case the GTK people might have fixed this in the meantime (I'm 
> still on GTK+ Version 3.24.5) and the only problem is with child frames 
> as in the OP.
>

I have version 3.24.37 here.

>> What would you suggest for this specific bug report?  The OP hasn't 
>> replied yet, so it's not yet know whether that advice solves their 
>> problem, but don't you agree that calling (redisplay t) after calling 
>> set-frame-size (and other similar functions) would in most cases help 
>> to have the frame "in sync" with the code?
>
> I'd agree if (1) the patch I posted earlier doesn't help and (2) the 
> problem above with normal top-level frames has not been fixed.
>

I just tried your "my-twiddle.diff" patch, and with your recipe above it 
doesn't help: it still produces either a 10x10 frame or a 20x20 frame. 
I'm don't know you mean by "the problem above with normal top-level 
frames".