bug#18136: 24.4.50; crash in redisplay when calling load-theme

[martin rudalics <rudalics@gmx.at>]

 > Why does it make sense to do that for TTY frames?  The terminal screen
 > cannot be resized from within Emacs, so the arguments for treating the
 > menu bar as an add-on are not really valid in this case.

The idea is that `frame-height' should have the same semantics on all
platforms.  If you think we can ignore this difference for TTY frames
I'm obviously OK with it.

 > Please ask questions about what you don't understand.  Having just
 > completed a debugging session for bug #18112, which was all about
 > assignment of TTY frame sizes, I think I can explain at least some of
 > that.
 >
 >> Probably this assignment
 >>
 >>         if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
 >> 	FrameCols (FRAME_TTY (f)) = new_cols;
 >>
 >> is completely misplaced and should be either removed or inhibited when
 >> called from change_frame_size_1, that is when INHIBIT equals 5.  Can you
 >> tell me what this assignment is for?
 >
 > It cannot be removed or inhibited.

Inhibited exclusively for the case that this function is called from
change_frame_size (that is when INHIBIT equals 5).

 > It was introduced to fix a bug
 > (#17875).  The problem is that different TTY frames on the same
 > terminal can potentially have different dimensions, and OTOH FrameCols
 > and FrameRows are "normally" set only at terminal initiation and in
 > response to a SIGWINCH signal.  These assignments take care of keeping
 > FrameCols and FrameRows in sync with frame dimensions in all other
 > cases, because they all go through change_frame_size.

Which means FrameCols and FrameRows always have the correct values when
entering adjust_frame_size and we shouldn't change them there.  Or am I
missing something?

martin