Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] Keep selected tab further from window edges (unless at one end of the tab list?) #313

Open
Kabouik opened this issue Apr 10, 2021 · 2 comments

Comments

@Kabouik
Copy link

Kabouik commented Apr 10, 2021

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?

@osa1
Copy link
Owner

osa1 commented Apr 11, 2021

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.

Would this work for you @Kabouik?

@Kabouik
Copy link
Author

Kabouik commented Apr 11, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants