Um, Vimium C now supports two types of tab order:

• if Vomnibar is in "tabs" mode, tabs are sorted by visitTime
  • all tabs in all windows can be searched
• if map T Vomnibar.activateTabSelection currentWindow=true, then when query is empty:
  • only tabs in the current window will be used to search
  • tabs are sorted in their native order (from left to right)
    • and listed in a tree mode (child tabs will have some space indents, if found)
  • the first tab is not the first tab of a window, but a tab at the left of the current tab
    • in case a window has too many tabs
    • those most left tabs will be shown if you use "pagedown"
    • this is an experimental feature, so I'm very appreciated if you may share any idea about it
• if query words exist, then tabs are sorted by text-matching scores.

And, a ":w" prefix of query string will make Vomnibar behavior like currentWindow=true.

Therefore, if you're using the "recommended settings", then t means "tabs in all windows" mode, and T means "tabs in current window" and "tree mode if query is empty".

If you prefer the old behavior, sorry but you may have to wait for 1~2 weeks for v1.76.4, which may add a new option to disable the tree mode even if currentWindow is true.

Oops, sorry, indeed I had map T Vomnibar.activateTabSelection currentWindow in my configuration on Firefox (not in Chromium). I removed it and tabs are sorted by visitedTime again, which is the most convenient behaviour to me. Sorry for bothering you and thanks for the help!

Then do you think in what situations you would like to use the "tree mode" ? The default limit of 10 items is indeed not enough to list all tabs for a common window.

If I understand correctly your description and the behavior that I see, the "tree mode" basically displays the tabs surrounding the currently selected tab. Is that correct? However, it's a bit confusing that for some tabs it shows two tabs to the left, and for others it shows only one tab to the left. I actually have never thought about such layout, so right now I'm not sure I can give any sensible feedback unless I live with it for a while. For me, having recently visited tabs at the top has always been enough because it's easy to switch between recent tabs, but if I need some tab that hasn't been visited recently and is not displayed, I usually remember part of its title.

As for the visual aspect of the "tree mode" -- to me, the space indentation does not seem to be enough. I mean it doesn't visually look like a tree. Maybe if you added some vertical and horizontal lines (similar to output of Linux tree command), it could have been more obvious. But then again, I've just discovered that mode hours ago.

What are your ideas about it? How did you come up with that "tree mode"?

Surrounding: Yes

One/Two: I want to make a "parent" tab of the current one the first item in a tree, and if no parent tab found, select the tab at its left.

Lines: Yes it would be better, but it's somehow so complicated that I haven't tried redesigning such a UI.

Then maybe I need to disable it by default, and use an command option to re-enable it.

@gdh1995 I think now it is actually broken. I checked my settings on Firefox, T is not mapped to anything, so the behaviour should be default. However, tabs are not sorted by visitedTime. Version 1.81.3, Firefox 74.0

1. those never visited

why? :( can I configure anything to revert this behaviour? I never want not visited to be on top, why would vimium-c push me into switching to those tabs? That was the brilliant part about having recent tabs on top that I could easily switch between them without remembering their title, and not doing extra search. now it's super confusing...

Well, then a next version will roll back to show those viewed at top and make the new order optional.

Thank you! I know how it can be diffucult to develop and support an open source project with these users, everyone's pulling in different direction, it's so hard to please everyone. I appreaciate the great work you're doing here on this plugin!