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

[Drew Adams]

I've been looking at this regression for a while now. I've tried to
investigate.  I just spent a couple of days on it, without success.

The symptom, with my setup (and it is not clear just which parts of that
setup are minimally required to repro the bug), is this:

When `set-frame-size' is called for the current frame (it doesn't matter
what the WIDTH and HEIGHT args are, and PIXELWISE is nil) in some Info
nodes (I see the problem only in Info nodes, and not most of them), the
mode line disappears altogether.

That is, in place of the mode line I see only blank space with the same
color as the frame background.  The space seems to be there for a mode
line, but none is shown.

Forcing redisplay using C-l or M-: (force-mode-line-update 'all) has no
effect.  But calling `set-frame-size' (e.g., using `M-:') can bring
back the mode line.  It does not do so if I call it with the same width
and height (a no-op in terms of size change):

(set-frame-size nil
                (frame-parameter nil 'width)
                (frame-parameter nil 'height))

But it does do so if I use a width or height that is even slightly
different from the current value, e.g.:

(set-frame-size nil
                (1+ (frame-parameter nil 'width))
                (frame-parameter nil 'height))

I'm guessing that perhaps the Emacs code detects that there is no
size change and so does nothing.  And not that the particular size
where no mode line is shown is somehow problematic.

Support for that guess comes also from the fact that if I thumbify
and then dethumbify the frame, which changes its size and other
parameters and then changing them back to what they were, also restores
the mode line. IOW, the frame is shown with the same width and height
parameters (and other parameters the same also), and with the mode line
present.

I was able to narrow down the time frame when this regression was
introduced: This build, from 2013-12-14 does not have the regression:

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-14 on ODIEONE
Bzr revision: 115521 rudalics@gmx.at-20131214110600-euy4wbseyg78zh72
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

And this build, from 2013-12-16 has the regression (as do all subsequent
builds):

In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2013-12-16 on ODIEONE
Bzr revision: 115543 rudalics@gmx.at-20131216095844-lbjh5yerk6ff0tm7
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'

I am sorry that I cannot provide more info, at least at this point.  I
have spent a *lot* of time trying to debug this already.  At this point
I am hoping that something in the info above will prove helpful.

I do not expect that you will be able to repro this easily, but perhaps
something above will ring a bell for you.  It is lucky, at least, that
the build window here is so short: two days.  I tried looking through
some of the development changes during that 2-day period, but I was not
successful in finding what might be the culprit.


In GNU Emacs 24.3.50.1 (i686-pc-mingw32)
 of 2014-02-28 on ODIEONE
Bzr revision: 116606 rudalics@gmx.at-20140228091055-seve9n9l9hg8dn2j
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
 `configure --prefix=/c/Devel/emacs/binary --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3' LDFLAGS=-Lc:/Devel/emacs/lib
 CPPFLAGS=-Ic:/Devel/emacs/include'