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

[Drew Adams]

>  >>  > So it seems that with the code after 2013-12-14 a nil value has
>  >>  > the same effect as a non-nil value (?).
>  >>
>  >> No.  The only difference is that the default value has changed.
>  >
>  > I meant wrt this latest reported problem.  Neither t nor nil fixes that.
> 
> That seems to contradict my guess.

I'm sorry; my bad.  Setting it to nil fixes this problem but brings back
the thumbnail frame problem (which is much more important for me).

>  >> But you could make sure that (1) the bug is here with 2013-12-14 when
>  >> you set `w32-enable-frame-resize-hack' to t and (2) the bug is not here
>  >> with 2013-12-16 when you set `w32-enable-frame-resize-hack' to nil
>  >
>  > Not sure what you mean. Which bug, the thumbnail frame problem or the
>  > current problem?  Please clarify what you would like me to try/test.
> 
> The current mode line problem.  Please try once more.  If setting this
> variable doesn't change anything, it can't be the cause and we have to
> look elsewhere.

I thought I already answered that.  Anyway, yes: if I set the var to t
in the 2013-12-14 build then I get the mode-line problem.  And if I set
it to nil in the 2013-12-16 build then that prevents the mode-line problem.

>  >> BTW: Does Info still display a header line when the mode line is lost?
>  >
>  > Yes.
> 
> Strange.

I can reconfirm that this is the case, however strange it may seem.
But this might be because of differences due to info+.el.  What is the
reason that you expect the header line to be lost along with the mode
line?