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

[martin rudalics]

> I set border-width to 10 and internal to 15.  First, some of the times
> when the mode line would have disappeared it did not do so.  Second,
> it did still do so sometimes - almost disappeared, that is.  In the
> latter case, what I saw (attached) was that, instead, part of the mode
> line disappeared, and there was no bottom border.

Good.  IIUC this shows that the display engine works correctly.  It
draws the mode line but somehow it gets clipped together with the
internal border.

> It seems we're getting somewhere now.

It will be just a sobering experience when we're there at last.

>> (3) Try to enhance `window--dump-frame' in a way that it does not erase
>>      its buffer and call it several times, immediately before and after
>>      you ask for a frame size change in `fit-frame'.  Moreover, you could
>>      add two lines to it with a suitable informatory text to display the
>>      values returned by
>>
>>      (w32-frame-rect frame)
>>      (w32-frame-rect frame t)
>>
>>      These are Windows specific so I can't include them in the
>>      `window--dump-frame' version that comes with Emacs.
>
> Attached also.  When fit-frame was called, it printed ------------.
> Then it called `window--dump-frame' 3 times.  Then it fit the frame.
> Then it called `window--dump-frame' 3 times again. `window--dump-frame'
> inserted a form feed, then the data.

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????)
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.

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.

> FWIW: Dunno whether it is related, but I have also seen this recently:
> Library pp-c-l.el shows a form-feed char in a pretty way, as shown here:
> http://www.emacswiki.org/cgi-bin/wiki/PrettyControlL.  This is
> still the case in general, but sometimes when a file with form feeds
> is first visited they appear normally, i.e., as ^L.  Even hitting `C-l'
> does not cause their proper display.  Eventually they are displayed OK.
>
> Perhaps Emacs redisplay is now happening less than was the case before?
>
> Dunno whether this is at all related to bug #16923 (which does not
> regain the proper display of the mode line at all).

FWIW this is completely unrelated.

martin