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

[Juri Linkov <juri@linkov.net>]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

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

I have one question: why menu-bar wrapping was not implemented on
TTY frames so far, why the design decision was to always truncate it?

This illustrates the question of how the menu-bar is truncated
whereas text in buffers is wrapped:


[-- Attachment #2: tty-menu-bar-truncated.png --]
[-- Type: image/png, Size: 10712 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2646 bytes --]


Maybe for the same reason why currently the menu-bar is one-line,
the tab-bar should be one-line on TTY frames.

For the same reason the header-line is one-line too, so the tab-line
should be one-line too.  This means that we still need to find
a solution how to scroll tabs on one line.

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

Since it's not clear how to do refactoring for multi-line tab-bar on TTY
and for multi-line tab-line, I'm going to explore the hscrolling option.

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

I started to implement adding truncation arrow buttons at both sides of
the one-line tab-bar, clicking on them will hscroll the tab-bar.

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

I tried to add newlines between tabs to force moving the wrapped tab
to the beginning of the next line on multi-line tab-bar.

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

Firefox provides both options at the same time: two arrow buttons to
hscroll tabs, and one dropdown button to pop up a menu of tabs.
It's easy to implement both.