bug#47234: 28.0.50; frame-inner-height fails without window system on tab-bar-height

[martin rudalics]

>> Then it's best to revert the frame.el part of 6c5ddf0e0b.
>
> Ugh!

My apologies.  I didn't expect anyone to care about this.

For the interested, a short history of that function: When I started to
implement child frames for Emacs, I noticed that while on Windows
everything worked OOTB, the various GNU/Linux systems I use provided no
mouse support for them at all.  So to avoid any unpleasant discussions,
I had to emulate the entire functionality in Elisp, several hundred
lines of code in mouse.el.

There, to make sure that child frames don't get too small during
dragging, I added a test where I compare the inner height of a frame
with that of the minimum size of its root window.  It's the inner height
because I have to drag the inner border of a frame - GNU/Linux doesn't
give me another choice.  And I wrote a separate function for retrieving
the inner height because `frame-edges' then appeared to expensive for a
function running in a tight loop like `mouse-drag-frame-resize'.

I didn't care about the menu bar (GNU/Linux generally doesn't like menu
bars on child frames) and the tool bar (so far I've not been able to
make a tool bar reliably show up on a GTK child frame).  So I silently
ignored these in `frame-inner-height'.  But I did notice recently, that
there's no reason why a child frame should _not_ have a tab bar and
that's why I made the change.

Hence, basically `frame-inner-height' is just an internal function (it
lacks the second "-" because it's defined in frame.el and used in
mouse.el) supposed to work exclusively in the very limited context of
frame dragging.  It's of absolutely no use on TTY frames but something
born out of the necessity to make Emacs work on systems lacking support
for certain features.

martin