You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When using C-p or C-n to move between previous and next tabs, I always overshoot when the tab I want is beyond the list limits, because I don't see it coming and I always press the keybind one or two extra times before realizing and going back.
How about shifting the whole list left and right and keeping the selected in the middle, or better, allow selected tabs to move left and right but keep it further from the window edges unless the beginning or the end of the list are visible?
My CLI email client does something similar when scrolling emails up and down in the inbox: when you go down from the top of the message list, the cursor goes down one unit at each keypress until it reaches the middle of the window, then it doesn't go below that and further keypresses make the whole message list move up, which continues scrolling but helps seeing context before and after the cursor. This also allows seeing when close to the top or end of the list.
Now Tiny cycles to the beginning when reaching the end of the list so maybe this behavior wouldn't work, but it might be worth discussing what other solutions could help better navigating through tabs. Or maybe we could combine this behavior with cycling from end to beginning of the list and just transition from rightmost position to leftmost when restarting the list, for better awareness of the current position?
The text was updated successfully, but these errors were encountered:
Good suggestion, I agree that this is a problem. We actually have the same problem in the input line and we solve it. If you move your cursor left and right when the input line is full, you will see that we show a few characters after the cursor as we scroll left/right. I think for consistency we should implement the same thing in the tab bar.
Here's how it would work. Let's say I have 6 tabs. |s indicate end of my screen, and * indicates which tab is currently active:
| tab1 *tab2 tab3 tab4 >|
Now if I do C-n it will look like
| tab1 tab2 *tab3 tab4 >|
Note that we didn't scroll just yet as we already have the next tab name visible. If I do C-n again:
| tab2 tab3 *tab4 tab5 >|
Now we scrolled a little bit to still show the next tab. If I do C-n again:
| tab3 tab4 tab5 *tab6 |
Because we've reached the end we don't show anything after tab6. You know this is the end because there isn't a > anymore.
Looks great! Exactly what I was trying to describe. What do you think should be the number of tabs between selection and window edges before Tiny starts to shift the list instead of the selection? I imagine one or two should be enough (and maybe two would be awkward actually).
I don't think we'd even need a > marker for the end of the list because we know that the selected tab could only be this close to the window edge if there are no other tabs next.
When using
C-p
orC-n
to move between previous and next tabs, I always overshoot when the tab I want is beyond the list limits, because I don't see it coming and I always press the keybind one or two extra times before realizing and going back.How about shifting the whole list left and right and keeping the selected in the middle, or better, allow selected tabs to move left and right but keep it further from the window edges unless the beginning or the end of the list are visible?
My CLI email client does something similar when scrolling emails up and down in the inbox: when you go down from the top of the message list, the cursor goes down one unit at each keypress until it reaches the middle of the window, then it doesn't go below that and further keypresses make the whole message list move up, which continues scrolling but helps seeing context before and after the cursor. This also allows seeing when close to the top or end of the list.
Now Tiny cycles to the beginning when reaching the end of the list so maybe this behavior wouldn't work, but it might be worth discussing what other solutions could help better navigating through tabs. Or maybe we could combine this behavior with cycling from end to beginning of the list and just transition from rightmost position to leftmost when restarting the list, for better awareness of the current position?
The text was updated successfully, but these errors were encountered: