GNU bug report logs - #37667
27.0.50; Tab Bar display problems with more than 5 tabs

Previous Next

Full log

View this message in rfc822 format

From: Juri Linkov <juri <at> linkov.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37667 <at> debbugs.gnu.org
Subject: bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs
Date: Tue, 15 Oct 2019 21:07:14 +0300

[Message part 1 (text/plain, inline)]

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

[tty-menu-bar-truncated.png (image/png, inline)]

[Message part 3 (text/plain, inline)]

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.