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: Wed, 30 Oct 2019 02:35:18 +0200
> 
> >   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 think this is the reason, because AFAICT tab-line-format
doesn't include constructs that would pad its elements with spaces.

Can you cook up a simple recipe where the truncation bitmaps don't
appear, and also show the patch you used not to reset those flags?
I'd like to look into what happens in the code in that case.

> 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.

Searching the current tab and displaying truncation indicators are two
separate tasks that don't necessarily need the same (or even similar)
code.  The former could be found much easier, I think.

> 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.

I don't think these two jobs are similar enough, but maybe I don't
understand well enough what you have in mind.  Can you elaborate how
you intended to search for the current tab?

> 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.

If you don't want the display code to produce glyphs, you should
arrange for it->glyph_row to be a NULL pointer.  See the call to
init_iterator inside format-mode-line to understand how this is done.
That function has the same problem as what you describe above.