thread.next / thread.previous: step into collapsed Working, Snoozed and Settled shelves

[imqdee]

Problem

thread.next and thread.previous (Cmd+Shift+] and Cmd+Shift+[ by default) walk the sidebar in its order: pinned, active, Working, Snoozed, Settled. They only walk rows that are drawn, though. A collapsed shelf, which is the default, is skipped entirely, so a snoozed or settled thread cannot be reached from the keyboard without first opening its shelf with the mouse.

Proposal

Let next and previous walk every shelf, collapsed or not, in the same order.

• Landing on a thread in a collapsed shelf draws that one row under the shelf header. The sidebar already does this today for the open thread.
• Stepping out of the shelf hides the row again.
• The saved open or closed state of each shelf never changes.
• Cmd+1 to Cmd+9 keep numbering only the drawn rows, so their hints stay correct.
• Settled is walked only as far as it is loaded, like "Show more".

No new command, binding, or setting.

Prototype

Branch: imqdee/t3code@main...sidebar-traversal-collapsed-shelves (about 70 lines in Sidebar.tsx and Sidebar.logic.ts, plus tests in Sidebar.logic.test.ts).

Walk from the last active thread into the collapsed Snoozed and Settled shelves and back (slowed 2x, test data):

MP4 version

Questions

1. Should stepping into a collapsed shelf open it fully and close it on the way out? The prototype draws only the current row, which keeps the sidebar still while stepping through a long Settled shelf.
2. With no thread open, thread.previous now lands on the last settled thread instead of the last active one. Is that acceptable?
3. The legacy sidebar groups by project and has no shelves, so the prototype leaves it unchanged.

If the direction and scope look right, I will open the PR against this proposal.

Related

• Improve screen reader accessibility with accessible mode and keyboard navigation #17754 proposes arrow key navigation in the sidebar as part of a broader accessibility package.
• Optional most-recently-used order for thread.next / thread.previous (or an Alt+Tab-style recent-thread switcher) #9751 asks for recently used order. This proposal keeps sidebar order.

[thienautran]

A question. When you traverse the sidebar shelf, and have a thread selected. Does the system focus move into context menus when keyboard based context is invoked ie the same as 2 finger click or right click? On windows you can right click or press shift + f10 or applications key.

Reason I ask is that if the system focus isn't transferred through, the context menu items are not able to be accessed via keyboard either, requiring mouse intervention when a context menu is invoked either via mouse click or keyboard activated. This would mean arrow keys cant move up and down within the context menu for a thread.

[imqdee]

Good question. No: next and previous switch the open thread, they do not move keyboard focus. Focus stays where it was, usually the message box, so Shift+F10 or the Menu key would not open that thread's context menu. Keyboard access to the row and its menu is the focus work your #17754 covers, so I kept it out of this proposal. The two should combine well: once a row can take focus, next and previous could move focus along with the open thread.

[thienautran]

Agreed, these would work very well together