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

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: 37667@debbugs.gnu.org
> Date: Thu, 31 Oct 2019 22:46:49 +0200
> 
> Detection of truncation is necessary as a separate function to decide
> whether to display arrow buttons in the tab-line.  When the tab-line
> is not truncated and displayed in its entirety, then there is no need
> to display arrow buttons for hscrolling.
> 
> >> We need to detect whether the current tab is before the right truncation 
> >> point
> >> (so it is visible), or after the truncation (so the current tab is not 
> >> visible).
> >
> > You already keep the number of tabs you've hscrolled off the display,
> > right?
> 
> Yes, the number of hscrolled tabs is kept in the window parameter.
> 
> > So if you also keep the number of the current tab, the above
> > decisions become trivial, no?  Or what am I missing?
> 
> To get the ordinal number of the current tab is trivial indeed, but when
> due to the large number of tabs preceding the current tab on the left side
> from it, it gets pushed off-screen behind the right window edge, we need
> to set the window parameter for the number of hscrolled tabs to such
> number of tabs that will reduce the length of displayed tabs on
> the left side from the current tab, so it becomes visible again.
> 
> C code is only need to calculate the number of tabs to cut on the left
> side from the current tab to make it visible.

AFAIU, there are several alternatives of how to go about the arrow
buttons that hscroll the tab-line:

 . Always display both of them, but make one or both of them do
   nothing when scrolling in that direction makes no sense.

 . Display one arrow on the left and another on the right, and decide
   whether or not to display the right one in display_mode_line,
   depending on whether you hit (last_visible_x - arrow_width) while
   producing glyphs.

 . Add a new function, exposed to Lisp, to provide indication for
   whether the right arrow will be needed, then use a proper
   tab-line-format to actually display the arrow.

It sounds like you decided to use the last alternative, but did you
consider the other two?  The first one sounds the easiest to me.  the
last one has a disadvantage that it does the tab-line processing
twice, once to determine whether the right arrow is needed, and then
again to actually display the tab-line.  Also note that adding the
right arrow will leave less screen estate for the tabs, so you need to
account for this somehow in your decision whether that arrow is
needed, lest displaying the arrow will make yet another tab partially
visible.

If you want to implement the last one, then you need a function
that calls display_mode_line and returns a truncation indication
depending on the state of it.glyph_row->truncated_on_right_p.  The
simplest way to achieve that is to add a new argument to
display_mode_line, which, when non-NULL, will be a pointer to the flag
where to return to the caller the truncation indication; then make
display_mode_line set that flag according to the truncated_on_right_p
flag.

Let me know if the above makes sense, or if you have more questions.