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

[Juri Linkov]

>> i.e. the columns '>' ('row->truncated_on_right_p')
>> and '<' ('row->truncated_on_right_p') both have values '0'.
>> 
>> Is this a bug?  Or maybe there is another way to detect tab-line truncation
>> in the glyph matrix?
>
> These flags are reset because display_mode_line forcibly resets them:
>
>   it.glyph_row->full_width_p = true;
>   it.glyph_row->continued_p = false;
>   it.glyph_row->truncated_on_left_p = false;
>   it.glyph_row->truncated_on_right_p = false;
>
> I think you will find that before the last two lines are executed, the
> truncated_on_right_p flag is set for the tab-line in your example.
>
> I think we need to make a change there to not reset the last 2 flags
> when we are displaying the tab-line.  (The full_width_p flag should
> still be set, because we don't want margin areas on the tab-line.)

I tried to not reset these flags only for the tab-line, and indeed
when the tab-line is truncated, then truncated_on_right_p is true
most of the time, but not always.  It's false when the tab-line
is truncated between tabs.

AFAIU by looking at 'display_string', it looks like this has something
to do with whitespace between tabs as this comment explains:

          /* Add truncation mark, but don't do it if the line is
             truncated at a padding space.  */

I don't want to modify display_string to take the tab-line
into account because more logic for searching the current tab
needs to be implemented anyway.  So maybe better to copy code from
display_string to a new function tab_visible_in_tab_line,
and beside detection of truncation also add more code to detect
a situation when the current tab is not visible due to truncation.

One thing that I don't understand where a function similar to
display_string will produce glyphs?  It should not touch the
real tab-line.  It should only check if the produced glyphs
push the current tab out of view.