bug#23320: 25.0.92; Window width not updated after frame resize (Win32 and GTK)

[martin rudalics <rudalics@gmx.at>]

 > I noticed a regression on 25.0.92 compared to 24.5 where the following code
 > behaves differently on the w32 port. (On a recent GTK build it also
 > misbehaves, but not under the NS port.)
 >
 >      (progn
 >        (set-frame-size (selected-frame) 1000 400 t)
 >        (window-width nil t))
 >
 > On 24.5, this evaluates to "1000". However, on 25.0.92 `window-width'
 > returns the width prior to the frame resize. (Evaluating it a second time
 > returns 1000, though.)
 >
 > Adding `(sit-for 0)' before the call to `window-width' make is return 1000
 > the first time, but it doesn't feel like a robust solution.
 >
 > Is this the expected behavior? If it is, is adding `(sit-for 0)' the
 > recommended way to get the correct window width after a frame resize?

Thanks for the report.  Just in due time to fix this for the release.
Moreover it allows me to remember the purpose of a change (something I
was unable to do in the discussion of bug#21380).  You can find the gory
details here:

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21380

The corresponding commit is:

commit 8af8355c3f72500986f6f10b62714b228d6f35ee
Author: Martin Rudalics <rudalics@gmx.at>
Date:   Mon Aug 31 11:09:22 2015 +0200

     Don't call do_pending_window_change in signal handlers (Bug#21380)

     * src/gtkutil.c (xg_frame_resized):
     * src/xterm.c (x_set_window_size):
     * src/w32term.c (x_set_window_size): Don't call
     do_pending_window_change.

which should also explain why the NS port was not affected.

I'm not sure how to proceed.  Probably I'll have to revert that commit
but the consequences are pretty unclear at the moment (at least to me).

martin