bug#28605: 26.0.60; Part of leftmost character hidden

[martin rudalics <rudalics@gmx.at>]

 >> I'm afraid you didn't test these with scroll bars turned off.  So it's
 >> easily possible that scroll bar calculations overshadow the frame size
 >> adjustments we do for handling the above.  Please try with scroll bars
 >> turned off before you test these.
 >
 > I've retested with scroll bars turned off, that doesn't make any
 > difference, the frame height still shrinks.

So for the moment we can omit scroll bars as the lone culprit.  They are
too complicated - theme based size, minimum size constraints - anyway.

 >> One thing you could check with scroll bars on is whether changing the
 >> frame width (or height) and undoing that gets us back the initial size.
 >> For example, does evaluating the following forms
 >>
 >> (set-frame-parameter nil 'width (+ (frame-parameter nil 'width) 5))
 >> (set-frame-parameter nil 'width (- (frame-parameter nil 'width) 5))
 >>
 >> in sequence result in a frame of the same size?
 >
 > Now that's weird. That gets me back to a frame of the same *width*,
 > but each invocation of set-frame-parameter reduces the *height*, and
 > gives me:
 >
 > (emacs:24843): Gtk-CRITICAL **: gtk_distribute_natural_allocation:
 > assertion 'extra_space >= 0' failed
 >
 > when I reduce the width (with or without scroll bars). Are we back at
 > "It's a GTK bug"?

Recently this was mostly due to /etc/PROBLEMS

*** Emacs built with GTK+ toolkit can unexpectedly widen frames

BTW I found Ola's tool and menu bar sizes very disproportionate.  Are
yours similarly large?

Anyway, the strategy now seems to be to switch off _everything_ toolkit
related (scroll bar, menu bar, tool bar and tooltips) and check whether
the problem persists.  If it does, something very fundamental is broken
and we at least know from where to start.  If it doesn't, then add each
of these but never two at the same time.  This should give as a next
clue.

martin