bug#1348: set-frame-width and set-frame-position seem buggy on at least MSWindows

[grischka <grishka@gmx.de>]

martin rudalics wrote:
>  > Below is a patch that fixes the problem on windows.
>  >
>  > As to X, it turned out that there is actually something
>  > similar, it calls itself "x_sync_with_move".
>  >
>  > Have fun.
> 
> Thanks.  I'm running Emacs now with your patch and will inform you if
> and when I find any problems.  But please be a bit less cryptic, at
> least when talking to illiterate people like me ;-)
> 
>  > +          if (-100 != sd)
> [....]
>  > +  w32_read_socket(-100, 0, NULL);
> 
> I suppose the -100 means to not handle "some" asynchronous resize
> requests while the WM handles ours.  So
>
Actually -100 doesn't mean anything except to let the "async_visible"
flag alone, because otherwise no frame showed at all, for some reason.
(okay, that WAS cryptic)

> - if a maximize, iconify, restore group request is enqueued we'd drop
>   most (or some) of it?
>
No, nothing is dropped.

> - if another asynchronous (not in the maximize, iconify, restore group)
>   size-related request is enqueued, we'd honor it - "instead" of ours?
> 
There is no "instead" with a queue.  What's in comes out, sooner or
later.

> - if a non-size-related request is in the queue we'd honor it - even it
>   has some of our code re-resize frames?
> 
Sure, as always.

> - if there's another frame we don't care about the
>   record_asynch_buffer_change (); stuff?
>
What buffer change? Resize doesn't change buffers, does it?

Btw, here is another incarnation of the issue:
http://lists.gnu.org/archive/html/help-gnu-emacs/2008-12/msg00034.html
("It doesn't work very well ...")