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: Tue, 15 Oct 2019 00:47:51 +0300
> 
> >> >> 2. Disable wrapping to the second line since it's not supported in -nw;
> >> >
> >> > Why isn't it supported on TTY frames, btw?  It seemed to me that the
> >> > infrastructure is there, i.e. we can have FRAME_TAB_BAR_LINES(f) > 1,
> >> > it's just that the code doesn't consider this possibility.
> >>
> >> Is it possible for TTY frames to use the same code that implements
> >> wrapping in multi-line tab-bar on graphical displays?
> >
> > I don't think I understand the question.  Which details of wrapping
> > multi-line tab bars seem to prevent doing the same on TTY frames?
> 
> I meant using the existing function tab_bar_height whose value increases
> FRAME_TAB_BAR_LINES, but TTY doesn't use FRAME_TAB_BAR_LINES.

tab_bar_height calls display_tab_bar_line, which is not used on TTY
frames.  We could make display_tab_bar_line work on TTY frames, but
then the question becomes why have a separate display_tab_bar function
for TTY frames instead of making redisplay_tab_bar support TTY frames
as well.

IOW, refactoring the code to have just one set of functions for both
types of frames would make sense, but we should refactor all of it,
not just a single function.

> >> 5. There is another alternative: display arrow buttons on both sides
> >>    of the tab-bar, clicking on arrows will hscroll tabs.
> >
> > On GUI frames, you get this for free by using the hscrolling machinery
> > and line truncation.
> 
> What is needed to enable it?

Add hscrolling support for pseudo-windows, I think.  It could start
with a specialized function to hscroll just the tab-bar, then the code
could just start displaying the tab-bar window starting at a button
that is not necessarily the first one.

> Does hscrolling depend on the position of point so point should be
> moved to the current tab to center other tabs around it?

I was talking about the truncation glyphs and clicking on them, not
about automatic hscrolling when point gets too close to the window
edge.

> Also I tried to insert newlines in the tab-bar string, without success.

Not sure I understand this part.  Why did you need to add newlines,
and what didn't work when you tried?

> >> 6. Or even better: clicking on such arrow buttons will pop up a menu of
> >>    remaining tabs that don't fit into one-line tab-bar.
> >>    This is like implemented recently for Info-history where clicking on
> >>    the tool-bar arrow pops up a menu of previous Info nodes.  The same way
> >>    clicking on the arrows on the tab-bar could pop up a menu of tabs whose
> >>    names don't fit into the one-line tab-bar at both sides of the current 
> >> tab.
> >
> > I'd leave such fancy features for future releases.  Remember: we are
> > waiting for this and other new features to reach some reasonable state
> > in order to start the Emacs 27 release cycle.
> 
> This is the simplest and quickest option to implement.  For Info-history
> it took just 20 lines of Lisp code.

The code could be small, but it will probably lead us down a rabbit
hole of more discussions, bug reports and feature requests, yet more
discussions, etc.  I'd like to stabilize this feature soon at some
reasonable point and leave the rest to future releases.