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

Previous Next

Full log

Message #83 received at 37667 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 37667 <at> debbugs.gnu.org
Subject: Re: bug#37667: 27.0.50; Tab Bar display problems with more than 5 tabs
Date: Fri, 18 Oct 2019 09:57:32 +0300

> From: Juri Linkov <juri <at> linkov.net>
> Cc: 37667 <at> debbugs.gnu.org
> Date: Fri, 18 Oct 2019 01:34:15 +0300
> 
> It seems before implementing this, first we need to decide
> what UI we could provide.  This decision affects a set of commands
> that needs to be implemented for tab-line hscrolling.
> 
> One variant is to allow dragging the tab-line by mouse where
> dragging to the left will scroll the tab-line to the left.
> But actually no web browser implements this behavior, they use
> dragging to move a tab to other place.
> 
> So maybe better to have two arrow buttons: clicking on the left arrow
> will hscroll to the left.

Agreed.  As we already have fringe bitmaps to show truncation both on
the left and on the right, arranging for them to be displayed for
tab-lines will allow us to bind clicking on these to scrolling
commands.

> Then we need two commands implemented in C: 'tab-line-scroll-left'
> and 'tab-line-scroll-right'.  And later to add some keys like
> 'C-x >' bound to 'scroll-left'.
> 
> These commands could work for the tab-line like hscrolling
> in the buffer works when 'auto-hscroll-mode' is 'current-line'.

There's an important difference, I think: you want to scroll the
tab-line in tab-button granularity, not one character at a time.  But
the principle and the main idea is the same, yes.

Previous Next

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