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

[Drew Adams <drew.adams@oracle.com>]

> From the backtrace you attached earlier it's clearly visible that in 21
> calls the value is 56.  And as I remarked earlier, this value is Windows
> internal.  So unless we have some proof that Emacs is asking Windows to
> do something like enlarging the title bar or wrapping the menu bar, we
> must assume that Emacs sent so many resize requests in a row that it was
> able to confuse Windows.
> 
> I have no idea how often you ask for changing the frame size in one and
> the same redisplay cycle.  On Windows, without ConfigureNotify events, I
> wouldn't issue more than one request per frame in one redisplay cycle.
> Everything else means asking for trouble.

In the debug output I sent, file throw-emacs-bug-16923.txt, you see,
as I mentioned, seven calls to `fit-frame' (each "------------" in the
file).  I was doing `s RET' in Info, non-incrementally searching for
the next occurrence of a string ("terminals").  Each press of `s'
entailed a single call to `fit-frame'.  In some cases a second
occurrence was found in the same node, so any `s' and its `fit-frame'
other than the first in such a node is essentially a no-op (except for
the bug side effect of removing the mode line).

Does that respond to your question about how often frame resizing is
requested per "redisplay cycle"?  I do not know the period, whether
in terms of a number of input events or elapsed time, of a "redisplay
cycle", but I can say that my pressing of `s' determined the calls
to `fit-frame': one per press.

And in the other test I did earlier, just using `M-: (fit-frame)'
twice in the same frame, the number of calls to `fit-frame' was two.

You say that you "assume that Emacs sent so many resize requests in
a row that it was able to confuse Windows".  What do you mean to draw
attention to here: the number of requests in a row or the rapidity or
frequency of resize requests?  What constitutes a "row", i.e., until
interrupted by what?

Based on what I say above, I do not see how it could be that either
a high cadence or a high number of successive `fit-frame' calls could
be overwhelming redisplay.  But I am entirely ignorant about redisplay,
and I am not very clear about what you are asking here.