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

[martin rudalics]

> 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