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

[martin rudalics]

>> Can you check whether input is pending before the 'sit-for' call?
>>
>
> input-pending-p invariably returns t in that recipe.

This is with the default value of 'x-wait-for-event-timeout', so
apparently the WM has answered our request.  If I set
'x-wait-for-event-timeout' to zero, I reliably get a 10x10 frame for the
non-child-frame case.  Which IIUC means that GTK skips the second
request.  What do you get when you set 'x-wait-for-event-timeout' to
zero for a non-child-frame without any redisplay?

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

But why would we want to _not_ process the ConfigureNotify event for the
first 'set-frame-size' call?  All (redisplay t) can do is to confirm
that the frame has still its initial size of 20x20.  Or what am I
missing?

> (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,

We still did not completely remove our earlier misunderstanding.  In the
"recipe for normal frames" there is no "child frame".  That frame is a
plain top-level frame - let's call it the "second" frame.

> 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.

This must be a red herring: sleeping or not sleeping before theses calls
cannot possibly affect what happens then, unless something like C-x C-e
interacts with the window manager.

> 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.

The real visible sizes or the ones reported via the message?

> 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,

As mentioned above, in this case we _do_ create a child frame.  Without
the parent-frame parameter, the initial 'make-frame' call produces a
simple top-level frame and not a child frame.  Child frames and
top-level frames are treated differently by the window manager in a
number of regards - a child frames moves together with its parent and
its position is always calculated relative to that of its parent.

> 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 fact that there's no difference between "before or between"
stumbles me ...

> the two calls to set-frame-size the result is always a 10x10
> child frame, and the message always "20 20".

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

... which again only hints at that GTK treats child frames differently
here.  It passes on the second request although the sizes are the same
as the initial ones.

> 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

There's one additional experiment you could conduct:

After you finished loading eval

(setq frame-size-history '(100))

then do the

(my/twiddle 20 20)

and then eval

(frame--size-history my/frame)

and look at the *frame-size-history* buffer.  Without (redisplay t) this
gets me

Frame size history of #<frame *scratch* 0x2620610>
size (1), TS=180x360~>90x180, TC=20x20~>10x10, NS=212x360~>122x180, 
IS=212x360~>122x180, MS=90x90
xg_frame_set_char_size, invisible, PS=212x360, XS=122x180, DS=122x180
xg_frame_set_char_size (5), TS=180x360~>90x180, TC=20x20~>10x10, 
NS=212x360~>122x180, IS=212x360~>122x180, MS=18x36 IH IV
size (1), TS=90x180~>180x360, TC=10x10~>20x20, NS=122x180~>212x360, 
IS=122x180~>212x360, MS=90x90
xg_frame_set_char_size, invisible, PS=122x180, XS=212x360, DS=212x360
xg_frame_set_char_size (5), TS=90x180~>180x360, TC=10x10~>20x20, 
NS=122x180~>212x360, IS=122x180~>212x360, MS=18x36 IH IV
ConfigureNotify, PS=212x360, XS=122x180, DS=212x360
xg_frame_resized, changed, PS=212x360, XS=122x180
change_frame_size_1, delayed, PS=212x360, XS=122x180, DS=212x360
change_frame_size (5), TS=180x360~>90x180, TC=20x20~>10x10, NS=212x360~>122x180, 
IS=212x360~>122x180, MS=18x36 IH IV

With your (redisplay t) it gets me

Frame size history of #<frame *scratch* 0x29cf610>
size (1), TS=180x360~>90x180, TC=20x20~>10x10, NS=212x360~>122x180, 
IS=212x360~>122x180, MS=90x90
xg_frame_set_char_size, invisible, PS=212x360, XS=122x180, DS=122x180
xg_frame_set_char_size (5), TS=180x360~>90x180, TC=20x20~>10x10, 
NS=212x360~>122x180, IS=212x360~>122x180, MS=18x36 IH IV
ConfigureNotify, PS=122x180, XS=122x180, DS=122x180
xg_frame_resized, unchanged, PS=122x180, XS=122x180
size (1), TS=90x180~>180x360, TC=10x10~>20x20, NS=122x180~>212x360, 
IS=122x180~>212x360, MS=90x90
xg_frame_set_char_size, invisible, PS=122x180, XS=212x360, DS=212x360
xg_frame_set_char_size (5), TS=90x180~>180x360, TC=10x10~>20x20, 
NS=122x180~>212x360, IS=122x180~>212x360, MS=18x36 IH IV
ConfigureNotify, PS=212x360, XS=212x360, DS=212x360
xg_frame_resized, unchanged, PS=212x360, XS=212x360

so that redisplay call is apparently responsible for getting us a second
ConfigureNotify event where we both recognize them as _not_ causing any
change.  Without the redisplay call we get one event indicating a change
from 212x360 to 122x180 pixels.  I'm not yet sure what to make of these
and would like to see what you get first.

Thanks, martin