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

[martin rudalics]

> 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