Tab handling improvements/extensions

[Enyium]

See commits.

If you're asking yourself what apps support a tab switcher that can be sufficiently controlled, Directory Opus does, for which I wrote a voice command set. I know that Firefox also has a tab switcher, but - to my knowledge - doesn't allow control about it like persistently showing it instead of only while holding a modifier key down. But I guess there's a chance that such apps will make persistent tab switcher dialogs available in the future, if their developers learn that it may be useful.

I saw Talon comes with an app.tab_detach() function slot, so I also made a phrase for it. It wasn't used before.

[nriley]

Suggested change

	tab (last | previous | left | up): app.tab_previous()
	tab (next | right | down): app.tab_next()
	tab (last | previous): app.tab_previous()
	tab next: app.tab_next()

From the community backlog session — we would prefer not to add multiple additional ways to refer to existing commands when the current commands would work even for vertical tabs.

[Enyium]

• It would be inconsistent to have "tab move left/right", but only "tab last/next". If you'd want to change the former, what would the phrases be?
• I find the relative "tab last/previous/next" to be not intuitive enough. Tab sequences don't have a strict reading direction like text. The user - like me - may have evolved various personal standards of ordering tabs for different situations that don't always harmonize with the meaning of "last"/"previous" and "next". Other phrases like for moving the cursor, and snapping windows also have directional phrases.

See also the second next conversation block.

[nriley]

Would recommend you call this tab hunt for consistency with other interactive filtering. Also, please add at least one implementation in an existing application supported by community (for example for Microsoft Edge; this should work on both Windows and Mac).

[Enyium]

I'd summarize the current uses of "hunt" as being related to either text searches (which includes symbol hunts in VS Code), or to searches for items out in the world or the periphery, i.e., not yet brought into your workspace, e.g., "file hunt", and web searches.

Neither of those two commands, which are derived from the respective window-related commands, do interactive filtering. The one capturing text immediately switches to the first tab matching the text (just like the window-related phrase); the one not capturing text simply shows all tabs, just like Windows' Alt+Tab dialog shows all windows (with rare exceptions of certain kinds of dialogs).

You could additionally have "tab hunt", which could replace the existing "tab search" that in fact is interactive (at least in Firefox), currently implemented for Chrome and Firefox.

Note that, as I wrote in #1840, I'd actually prefer "switch" to "focus" (but not introduced by this PR, of course).

[nriley]

Until dynamic list support gets released (which makes such commands work great; I've built several of them now) I'm not sure what benefit a non-searching <user.text> capture has, other than potentially confusing users. Since there was no implementation in your PR it was hard to tell what it did.

[Enyium]

Until dynamic list support gets released (which makes such commands work great; I've built several of them now)

I don't know what that means including "such commands".

I'm not sure what benefit a non-searching <user.text> capture has, other than potentially confusing users.

It's not exactly <user.text>, but this is very similar. There are possible ambiguities with both. First, the user is responsible for mentioning text that's unique enough to get the match they want in the first search result, which will automatically be confirmed; second, apps may order the search results such that the current window's tabs are at the top, or the last visited ones are at the top. If they get too many incorrect tab jumps with tab focus <user.text> in a certain app, they'd naturally go over to using tab hunt <user.text> (or however you'd call it) in that app to get the search results presented first. Or they'd use the one or the other, depending on how unique they think the text they're about to mention is.

Jumping directly to a tab using a search that the user isn't interactively involved in is an alternative to activate a tab that the user sees on the tab bar, but which isn't adjacent to the currently active tab, by visiting every tab in between, destroying their last-tabs-visited history, and also relieves them of the obligatory confirmation step, if they know what they want. Switching tabs is a very common occurrence that shouldn't involve unnecessary work; you should be able to be agile with it.

[nriley]

From the community backlog session — we did not think this was a great name for this command, specifically because "tab focus last" and "tab last" do two different things, but also couldn't think of a better one. Since you do not have an implementation for this we would recommend that you just remove it from the PR and potentially suggest some other names.

[Enyium]

(You seem to only refer to the last code line with tab focus last.)

If tab focus <user.text> and tab focus$ stay (see misunderstanding above), it would only be consistent with the window-related phrases to not deviate from them regarding this phrase.

"last" is ambiguous (temporal vs. spacial meaning), and inconsistently used in repo. It should actually be standardized - to the temporal meaning, in my opinion. This would mean deprecating "tab last", or making it an alias of "tab focus last".

One could provide a simple implementation for some app where pressing Ctrl+Tab always switches to the last active tab, and not just to the tab to the right of the active one. That'd be a start. It could be Notepad++, but it has a setting to change it, whose default value I don't yet know.

[nriley]

Absolutely — "last" is extra confusing in whether it means "item selected before the current item" (temporal) or "item before the current item" or "final item" (spatial).

One benefit is that it's quick to say when compared with some of the other options (e.g. "previous"), and it's pretty consistently indicating "item before the currently item" in community. Breaking the speech patterns of everyone who uses community is not something we do lightly.

I just thought of tab most recent, which is comparatively unambiguous. Rango uses tab back (https://rango.click/#/?id=focus-tabs) and also supports tab hunt (which does not trigger interactive filtering but I guess tries to do something like your user.tab_switcher_focus?). As we build out more sophisticated tab commands we could consider migrating some of the actions from Rango into community to avoid conflicts as there have been between Cursorless and community.

[Enyium]

In my understanding, you never need the meaning "temporally next", because - when not working with timelines - you're always at the edge of history/time. This would leave "next" as always meaning "spacially next", if you really need an implied order. So, the question is what the opposite implied-spacial-order word should be, and what it's temporal equivalent should be.

I also don't like tab previous, because it's so long. Since prev is a common abbreviation, I'd rather say that than previous (people pronouncing it, starting at 12th video; Talon doesn't seem to have a problem with both pronunciations).

["last" is] pretty consistently indicating "item before the currently item" in community.

By number of occurrences in community, or by average uses per day? The latter is what primarily conditions people's minds. I think phrases like focus last can be expected to be used quite often, which has the temporal meaning.

tab most recent has as much syllables as tab previous, and it could be the most used tab switching phrase. Since a long time ago, I have a button on my trackball programmed to press Ctrl+Tab, because I use it so often, while my Firefox uses last-used tab order with this shortcut.

I'd like to promote conceptual consistency, with concepts that are as fitting as possible. Having tab back, but (focus | switch) last would be inconsistent. focus back sounds strange. If focus would be changed to switch, switch back actually works. But how important is the spacial meaning of "last" to you? And do native English speakers really find it more intuitive than its temporal meaning? As you said, which I didn't even have in mind, the spacial meaning of "last" is even ambiguous in itself. Is that definition really worth keeping, instead of saying, once and for all, we'll only use it temporally?

---

Rango's tab hunt doesn't really fit. Hunting involves going through possible options, and judging about their suitability. Hunting is immersive. The one hunting is Rango's algorithm. But I think the interpretation that tab hunt completely delegates the hunting work to Rango's implementation, not requiring you to lift a finger, is much weaker than the interpretation that you are involved, and required to further judge about the results. If we come up with a more fitting phrase here (tab focus..., or later rather tab switch?), why not offer it to Rango instead? I think it should be avoided that we entangle ourselves in inconsistency.