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

[martin rudalics]

> 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