[ISSUE] Conflict with Kanban Group By X and Prev/Next Tab Keymaps

[dwarjie]

• Date: 2026-08-11
• Severity: Low
• Environment:
• OS: MacOS 26.3 (25D125)
• Software version: 2.27.0

ISSUE

Kanban view of Task has a keymap for group by x using g key. This has a conflict to the default keymap of next tab with a gt and prev tab with a gT.

Trying to use gt or gT in the Kanban view will only result in changing the grouping of the Kanban.

If the user wants to preserve the default next/prev tab keymaps, the only way to resolve this issue is to change the keymap of group by x. But, upon checking the keymaps, this is not currently possible.

[adibhanna]

Fixed on the current development branch in df195a3. Thanks for the precise report, and you read the situation exactly right: the board's own key handler ran ahead of the tab keymap and consumed g before the gt/gT sequence could start.

The fix. In Vim mode, when the pressed g opens one of the tab sequences, the Kanban now waits the same half-second window the tab keymap uses instead of cycling immediately:

• gt / gT from the board switch tabs, with the grouping untouched.
• A bare g still cycles the grouping when the window expires, so the binding the board shows keeps working, just one beat later.
• Any other key after g drops the prefix vim-style and acts normally.

Both bindings survive rebinding too: the board resolves the tab sequences from the keymap settings, so if you move Next/Previous tab off the g prefix (Settings, Keymaps), the group-by cycle goes back to firing instantly. With Vim mode off nothing changes at all.

Verified by driving the built app: from the board with a note tab open, gt lands on the note with the grouping unchanged, gT returns, and g alone cycles exactly one step.

Ships in the next release.