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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 8 Mar 2014 07:34:54 -0800 (PST)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 16923@debbugs.gnu.org
> 
> > 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.

Every time Emacs waits for input, it automatically enters redisplay.
So, unless you typed a series of 's' keys faster than Emacs could
process them (which I doubt, since you probably looked at the search
results before pressing the next 's'), each 's' keystroke would account
for one redisplay cycle.  If you took your time reading before you
pressed another key, there could be more than one redisplay cycle
between every two 's' keystrokes.

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

Perhaps Martin meant something other than the redisplay cycle I
described above.