bug#19972: Font size change doesn't update (window-total-width)

[martin rudalics <rudalics@gmx.at>]

 > Feel free to ignore, btw.  But to clarify, what I had in mind was call
 > MoveWindow, and wait for WM_SIZE before we call change_frame_size.  I
 > have no idea whether this is a good idea, though.

It's not the idea that bothers me but the implementation.  Looking at
what Jan did in x_wait_for_event it seems very unlikely that I could
come up with an equivalent solution.  Think of the input un-/blocking
part:

   int level = interrupt_input_blocked;
   ...
   while (f->wait_event_type)
     {
       pending_signals = true;
       totally_unblock_input ();
       /* XTread_socket is called after unblock.  */
       block_input ();
       interrupt_input_blocked = level;

Would this work on Windows?  And on Gtk he does

       (void)gtk_events_pending ();
       gdk_flush ();

before calling x_wait_for_event.  Would we have to flush old messages on
Windows and if so how?  All this is probably over my head.

 > But in any case, are you saying that if we call change_frame_size with
 > dimensions that Windows doesn't like (can that happen?

I'm quite confident that Drew will eventually come up with an
appropriate scenario.

 > ), then we will
 > get a WM_SIZE message telling us to change the size to something else?
 > Does this really happen under some conditions?

ISTR that I was suprised by Windows once or twice doing that but I can't
give you any details any more.  Windows is very attentive in this
regard.  OTOH it is by far the most permissive system wrt which changes
it allows.

martin