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

[Eli Zaretskii]

> Date: Tue, 29 Jul 2014 12:44:22 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 18136@debbugs.gnu.org
> 
>  > I don't understand why you subtract FRAME_MENU_BAR_LINES, that sounds
>  > wrong at least for TTY frames.  (We could add that back inside
>  > adjust_frame_size, but it's IMO a bad idea to spread this non-trivial
>  > logic between 2 functions.)
> 
> All functions like change_frame_size or adjust_frame_size now expect the
> frame's text height as argument and menu and tool bars should not be
> part of it.

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.

> I was expecting some breakage of this approach for TTY frames
> because I didn't fully understand the logic of how frames get
> assigned sizes.

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