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

[Gregory Heytings <gregory@heytings.org>]

>
> The scroll bar is displayed and hidden repeatedly in either case- The 
> surprising thing is that with GTK3 the frame shrinks continuously.
>

It doesn't here.  Just in case, I tried a few different window managers 
(IceWM, Fluxbox, Window Maker, ...) and the result was the same: the 
scroll bar is displayed and hidden repeatedly, but the frame size doesn't 
change (except of course by the few pixels that are used to display the 
scroll bar).

>> But ISTM that telling Elisp programmers that such requests are 
>> "committed" asynchronously, and that they can "commit" them immediately 
>> by calling (redisplay t), should solve most similar problems.
>
> People changing the tab bar or the default font may be hardly aware of 
> the fact that the toolkit stochastically resizes their frames behind 
> their backs.
>

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?