bug#16923: 24.3.50; reression: `set-frame-size' loses mode line

[Drew Adams <drew.adams@oracle.com>]

> It seems easy to spot the problem - it should be
> w32-rect: (0 0 635 912), (0 0 627 832)
> ...
> w32-rect: (0 0 635 828), (0 0 627 748)
> ...
> w32-rect: (0 0 707 912), (0 0 699 856) <--- here
> ...
> w32-rect: (0 0 635 912), (0 0 627 832)
> 
> The difference between the height of the outer rectangle (which includes
> title and menu bar and decorations) and the client rectangle shrinks
> from 80 to 56 pixels.  I suppose that all parts exclusively in the outer
> rectangle (title, menu bar, ...) are still here as before (are they????)

Sorry, I don't quite follow you.
Just what are you asking me to check (and how)?

> which means that there are 24 pixels less for the client rectangle and
> Windows partly draws the frame decoration over it and clips the rest.
> 
> Prepare a function to print the difference of the (nth 3) of the two
> `w32-frame-rect' calls in the echo area of a second frame, bind it to a
> key, and you should see that whenever the modeline is absent that value
> is 56 while otherwise it is 80.

Sorry, I really do not know what you would like me to do.
Please elaborate.

> Note that `w32-frame-rect' is purely build from Windows API calls - that
> is, the raw values are provided by Windows and Emacs only converts them
> to coordinates.  So at first sight this looks like a Windows bug.
> Windows should never return another difference unless, for example, the
> menu bar wraps.
>
>  >> It looks like a timing error where Emacs and Windows have different
>  >> conceptions about the size of the Emacs frame.  Maybe locally binding
>  >> `w32-enable-frame-resize-hack' to nil around the `fit-frame' calls
>  >> would help.
>  >
>  > Actually, that does seem to help.  It seems to solve the problem.
>  > Let me know, after looking over all of this information, whether you
>  > think something can be or needs to be fixed on the Emacs side for
>  > this bug, or whether I should just wrap such a binding around the
>  > body of `fit-frame'.
> 
> It's a fragile fix.  But I have no better solution at the moment.

OK, I guess I'll make that change, then.  Can you say what is fragile
about it?  Do you expect that it will break something?  Or do you mean
only that it might not work in all cases?  (Or do you mean something
else?)