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

[martin rudalics]

> 1. Ensure, I think, that the only calls to `set-frame-size' are from
> my calling `fit-frame' interactively (via C-x C-_).  Nothing on
> `post-command-hook' that invokes `set-frame-size', for instance.
>
> 2. Resized a frame manually (with the mouse), so that the next call
> to `fit-frame' would actually change the size (to fit the buffer text).
>
> 3. C-x C-_ (`fit-frame'), which fit the frame, with no loss of the
> mode line.
>
> 4.  C-x C-_ again, which fit the frame (as a no-op, no size change
> needed), this time with loss of the mode line (the bug).
>
> Attached is the log, *window-frame-dump*.  After #3, I added a
> line of zeros to the buffer, to make clear where the second call to
> `fit-frame' (hence `set-frame-size') occurred.

Thanks.  The problem is that while in the first dump Windows and Emacs
agree about the frame's pixel height as

frame pixel: 511 x 528   cols/lines: 73 x 44   units: 7 x 12
                   ^^^
frame text pixel: 490 x 528   cols/lines: 70 x 44
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 519 608), (0 0 511 528)
                                  ^^^
they disagree in all remaining dumps

frame pixel: 728 x 828   cols/lines: 104 x 69   units: 7 x 12
                   ^^^
frame text pixel: 707 x 828   cols/lines: 101 x 69
tool: 0  scroll: 21  fringe: 0  border: 0  right: 2  bottom: 2
w32-rect: (0 0 736 884), (0 0 728 804)
                                  ^^^
by 24 pixels, incidentally (maybe) the equivalent of two lines of 12
pixels.  Please try two things now:

(1) Repeat the test once with a default character height of 11 pixels
    and once with say 14 pixels so we can tell whether the two lines
    paradigm holds.

(2) Try to replace `fit-frame' by (set-frame-size nil 101 69) so we can
    eliminate `fit-frame' as possible source of the problem and have an
    easier repeatable scenario.

martin