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

[martin rudalics <rudalics@gmx.at>]

 > Why can't it wait?  A couple of frames doesn't sound like thousands
 > and also you probably would not start editing your files while your
 > frames are still moving around.  So it wouldn't make any difference
 > on the user level, except that you'd get correct results by design.

I have never looked into that code.  IIUC one problem is flickering when
a frame gets redrawn too often.  Moreover, it's not always safe to
redraw frames.

 > And then it can of course (and probably should) handle other events
 > while waiting for the ConfigureNotify.  In GUI apps it is normal that
 > "wait" doesn't mean just sleep or block.

Sounds rather like an additional complication.  At the time we call
`set-frame-height' we want to execute Lisp code.

 > Btw, on ms-windows such serialization is built-in actually. With
 > a call like "SetWindowPos" you'd get the WM_WINDOWPOSCHANGED message
 > with the new coordinates and sizes before the call returns.

Isn't this WM_WINDOWPOSCHANGING?  In any case, it seems we still
wouldn't know how many lines the menubar occupies, or am I missing
something?

I'm currently aware of the following bugs WRT frame management on
Windows:

- One can set the frame size only once in a command - that's the bug
   we're talking about here.

- It may take some time to redraw an Emacs frame after removing another
   frame that obscured it (see also Bug#117 and Bug#950).

- All sorts of problems reported by Drew Adams in Bug#117.

Contributions to fix any of these are most welcome ;-)

martin