bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs

[Juri Linkov]

>> Thanks for the explanation.  One thing that I still don't understand is
>> how to find the exact position in the mode-line string where it's
>> truncated.  For example, in the string "...abc|xyz", the part
>> until "abc" is visible, but the rest of the string is truncated,
>> so "xyz" is not visible.  How to find this position where truncation occurs?
>
> You should look for that in the glyphs, not in the string you want to
> display.
>
>> Actually, it seems I found it, it's it.last_visible_x.  Is this correct?
>
> it.last_visible_x is the first pixel that is _outside_ of the
> viewport.  The last pixel that is still visible has X coordinate one
> less than that.
>
> Also note that when a screen line (a.k.a. "glyph row") is hscrolled,
> its display doesn't starts when it.current_x is zero, it starts when
> it.current_x is it.first_visible_x.

It seems before implementing this, first we need to decide
what UI we could provide.  This decision affects a set of commands
that needs to be implemented for tab-line hscrolling.

One variant is to allow dragging the tab-line by mouse where
dragging to the left will scroll the tab-line to the left.
But actually no web browser implements this behavior, they use
dragging to move a tab to other place.

So maybe better to have two arrow buttons: clicking on the left arrow
will hscroll to the left.

Then we need two commands implemented in C: 'tab-line-scroll-left'
and 'tab-line-scroll-right'.  And later to add some keys like
'C-x >' bound to 'scroll-left'.

These commands could work for the tab-line like hscrolling
in the buffer works when 'auto-hscroll-mode' is 'current-line'.
Also their ARG could be like in 'scroll-left' where the default ARG
is window width minus 2.