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

[martin rudalics <rudalics@gmx.at>]

 > I don't have strong feelings about it, and will probably adapt if we
 > stay with this semantics.  But it feels strange, as on a TTY the menu
 > bar is a line just like any other line, and when the menu bar is not
 > displayed, I'd expect that line to be used for text.

The one use case I can think of is the following: Someone tries to do
something special if a specific frame is not as high as needed for
displaying some sort of text.  In this case it would be nice to have a
uniform behavior.  But the point is rather moot since the object of
reference in this regard is the window and the frame height also counts
in the minibuffer and a modeline.  So I have no strong feelings about
this either.

Note that this was an attempt to make the various toolkits behave more
similar.  But so far I failed in a number of aspects.  For example, I
was not able to keep the frame height constant when adding/removing the
menubar in fullheight mode on a number of GUI builds.

 > E.g., with your suggested semantics, what would you expect from this:
 >
 >    emacs -Q
 >    M-: (frame-height) RET
 >    M-x menu-bar-mode RET
 >    M-: (frame-height) RET
 >
 > Would you expect to see the 2 results of frame-height identical or
 > different?

Ideally different in fullscreen/maximized/fullheight mode or with
`frame-inhibit-implied-resize' non-nil, identical otherwise.

 > Again, FrameRows and FrameCols updates are triggered in 3 possible
 > ways:
 >
 >    . when the terminal is created
 >
 >    . when we get SIGWINCH
 >
 >    . when we call change_frame_size
 >
 > The last one was missing, which caused bug #17875, whereby switching
 > to a different frame on the same terminal failed to update FrameRows
 > and FrameCols, because neither of the first 2 triggers happened.

My bad.  For some reason I thought these were set in change_frame_size.
Is calling change_frame_size necessary when switching frames?  What a
strange thing to do.

martin