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

[Eli Zaretskii <eliz@gnu.org>]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Mon, 21 Oct 2019 01:28:52 +0300
> 
> > Agreed.  As we already have fringe bitmaps to show truncation both on
> > the left and on the right, arranging for them to be displayed for
> > tab-lines will allow us to bind clicking on these to scrolling
> > commands.
> 
> Trying to click on truncation arrows in fringe bitmaps of buffers signals:
> 
>   <right-fringe> <mouse-1> is undefined
> 
> So we need to bind <mouse-1> to a tab-line scrolling command
> for [tab-line right-fringe] keymap?

Either that, or bind the click on the fringe to a command that looks
at posn-area of the click event, and scrolls the tab-line of the area
is tab-line.

> Or maybe the tab-line could be dragged like dragging the
> horizontal scroll bar in horizontal-scroll-bar-mode?

That would prevent using the drag events for something else, like
reordering the tabs.  It is also not what other applications do,
right?

> Or mouse-wheel could scroll the whole tab-line horizontally
> instead of switching tabs like it does now?

That could be an additional feature, but it cannot be the only one, I
think, because some mice have no wheel.

> >> These commands could work for the tab-line like hscrolling
> >> in the buffer works when 'auto-hscroll-mode' is 'current-line'.
> >
> > There's an important difference, I think: you want to scroll the
> > tab-line in tab-button granularity, not one character at a time.  But
> > the principle and the main idea is the same, yes.
> 
> I thought that granularity should be wider: scrolling by the window width,
> like 'C-x >' ('scroll-right') does, where default is window width minus 2.

I think this would be less convenient.

> But maybe tab-button granularity is fine.  The only problem is that
> I still studying the code to understand where to begin.  Could you suggest
> in what function to implement all this scrolling?

I think you will need a new function.  A tab-line is generated from a
Lisp string, and we don't have code for hscrolling screen lines
produced from strings (as opposed to from buffer text).

The general idea is to identify the first (leftmost) tab you want to
be visible, and then make changes in display_mode_line to start
display from that tab.  I think the first part is the more complex of
these two.  format-mode-line shows an example of how to generate
display derived from Lisp and C strings without displaying anything;
you could use that for finding the X coordinate (in it.current_x) of
the beginning of the Nth tab's button.  Each click on the right fringe
increases N, each click on the left decreases it.  The X coordinate
you compute is the value to use for it.first_visible_x in
display_mode_line.

I hope this makes enough sense to get you going.  If not, please ask
more specific questions.

Thanks.