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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 31 Jul 2014 10:49:11 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: mvoteiza@udel.edu, 18136@debbugs.gnu.org
> 
> But I don't really understand about `set-frame-height' and friends on a
> TTY and what they are supposed to do.  Should these be allowed to change
> the frame size?

Yes.

> Now about the
> 
>      change_frame_size (XFRAME (selected_frame),
>                         FrameCols (t->display_info.tty),
>                         FrameRows (t->display_info.tty)
> 		       - FRAME_MENU_BAR_LINES (f), 0, 0, 1, 0);
> 
> call in init_display.  What precisely is this supposed to accomplish?

Allocate the glyph matrices, at the very least, I guess.

> Back to init_display and the question I asked earlier: Why should the
> subsequent adjust_frame_size call do
> 
>        if ((FRAME_TERMCAP_P (f) && !pretend) || FRAME_MSDOS_P (f))
> 	FrameRows (FRAME_TTY (f)) = new_lines;
> 
> here?

Maybe it shouldn't, when called from init_display.  But we should at
least leave an eassert there, in case we overlook something.

In any case, this begs the question: why do you at all call
adjust_frame_size in this case, if the frame already has the required
size?  I think the answer is that adjust_frame_size does something
else: it calls adjust_frame_glyphs.  That call is required at
init_display time for obvious reasons, but it is inside
adjust_frame_size which is only called when the frame size changes,
which sounds like a contradiction in the design.

> Now please tell me one thing: Which calls of change_frame_size or
> adjust_frame_size _should_ set FrameRows or FrameCols

Any calls that actually change the frame size.

> and how can I distinguish them?

You already do, if I understand your description.  You already avoid
calling adjust_frame_size unless the size really changes.