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: Thu, 31 Oct 2019 02:03:51 +0200
> 
> >> 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.
> 
> Before starting to search the current tab, the code needs to known
> whether truncation really occurred.

Can you explain why?  Don't you keep the ordinal number of the current
tab somewhere?  If not, can you keep it?  Given the number, finding
the tab should be trivial, no?  (At least for some values of "find".)

> 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?  So if you also keep the number of the current tab, the above
decisions become trivial, no?  Or what am I missing?

> It seems searching for the current tab is not possible in the glyph matrix,
> because when the current tab is after the truncation point, then its
> glyphs are not produced.

If we arrive at the conclusion that using the tab numbers, as I
suggest above, is unworkable, then it would make sense to search it by
walking the glyphs.  I don't think it will be hard, let alone
impossible, but let's first see why not do this in Lisp.

And btw, why do you need to "find the current tab"? for what feature?

Thanks.