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

[Drew Adams]

> So the window code calculated 14 pixels for the mode line which
> subsequently either got lost in the display engine or was cut off by the
> window manager.  It would be still interesting to see a high resolution
> screenshot of the lower part of your frame.

Attached.

> A list of things you can try:
> 
> (1) You have set frame parameters for right and bottom dividers.  Maybe
>      they interfere, so try without them.

OK, I tried that. It changed nothing.

> (2) Set the `border-width' and/or `internal-border-width' parameter of
>      your frame to some number and look whether a border stays visible at
>      the bottom of a frame whose window lost its mode line.

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.

It seems we're getting somewhere now.

> (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.

So each `fit-frame' call starts with ------------.  It is followed
by 6 sets of data printed by `window--dump-frame', each introduced
with a form feed.

> In any case, if setting `w32-enable-frame-resize-hack' does make a
> difference, I doubt that we can really do anything about this.

I certainly hope you can, though this is not a critical bug.

(It is a regression, in any case.  It should be *possible* to remove
it, since at one time it was not there. ;-)  Of course, that does not
mean that it must be easy to remove it or that removing it and possibly
sacrificin other benefits is TRT.)

> 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'.

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

throw-emacs-bug-16923.png
Description: PNG image

throw-emacs-bug-16923-w-borders.png
Description: PNG image

throw-emacs-bug-16923.txt
Description: Text document