Allow tab navigation without leaving Navigate mode

[Angel-O]

Navigate mode supports movement at two levels of Herdr's hierarchy:

• navigate_workspace_up / navigate_workspace_down select a workspace
• navigate_pane_left / navigate_pane_down / navigate_pane_up / navigate_pane_right select a pane

There is no equivalent Navigate-mode action for selecting the previous or next tab. The normal previous_tab, next_tab, and switch_tab bindings cut off the continuous Navigate-mode flow. Literal Tab is also prohibited as a Navigate-mode binding.

#1850 fixed Navigate mode exiting after the first pane-focus movement, but tab switching remains a missing level between workspaces and panes.

Proposed behavior

Add configurable Navigate-mode tab actions, for example:

[keys]
navigate_tab_previous = "shift+left"
navigate_tab_next = "shift+right"

The exact defaults are flexible, but invoking either action should switch tabs while keeping Navigate mode active, just as workspace and pane movement now do.

Why

Herdr navigation is hierarchical:

workspace -> tab -> pane

A keyboard user should be able to enter Navigate mode once, move to a workspace, select one of its tabs, then select a pane before explicitly accepting or cancelling. Currently the middle step is unavailable, so selecting a different tab interrupts the flow and requires re-entering Navigate mode.

This would complete continuous keyboard navigation across all three structural levels without changing existing bindings. The actions should be configurable so users can choose keys that do not conflict with their pane-navigation layout.

Originally filed as #2076 before the automated guidance clarified that feature requests belong in Discussions.

[Angel-O]

A clarification on the natural bindings: Tab already performs tab pane navigation while Navigate mode is open, but doing so exits Navigate mode and cuts off the continuous navigation flow.

The most natural behavior would therefore be:

• Tab: move to the next tab and remain in Navigate mode
• Shift+Tab: move to the previous tab and remain in Navigate mode

This would preserve the existing Tab interaction rather than introduce unrelated shortcuts, while completing the workspace -> tab -> pane navigation hierarchy. The current config validation restrictions around tab/shift+tab for generic Navigate-mode movement fields should not dictate the UX for dedicated tab-navigation actions.

[Ken-vdE]

I would love this feature too.
I have shift+j and shift+k bound to navigate_workspace_down and navigate_workspace_up and want to set shift+h and shift+l to previous and next tab in navigation mode too.
prefix+n and prefix+p doesn't quite do it and navigation mode feels like the perfect place for it.

P.s. Tab does not switch tabs for me in navigation mode?

[Angel-O]

P.s. Tab does not switch tabs for me in navigation mode?

yes that's right: I meant pane. I'll edit the comment: thank you

[Andiveli]

I have a closely related navigation use case: using one horizontal key pair to move between panes and cross into the previous or next tab only when there is no adjacent pane in that direction.

Today, separate pane and tab bindings interrupt the spatial navigation flow. For example, pressing left from the leftmost pane would select the previous tab, while pressing right from the rightmost pane would select the next tab. Movement between panes inside the current tab would remain unchanged.

This complements the proposal to keep Navigate mode active by making the workspace -> tab -> pane hierarchy feel continuous at pane boundaries. Would this boundary fallback fit within this proposal, or should it remain a separate idea?