Snooze the active thread with a keyboard shortcut (thread.snooze)

[jpsirois]

Problem

Snooze has no keyboard path. To snooze a thread, you hover its sidebar row or open its action menu, then pick a preset with the mouse.

Settle (#8089, mod+shift+s), pin (#8440, mod+shift+p) and undo (#12848, mod+z, which also undoes a snooze) are bindable thread.* commands. Snooze is not in THREAD_KEYBINDING_COMMANDS in packages/contracts/src/keybindings.ts, so nobody can bind it.

Proposal

Add a thread.snooze keybinding command for the active thread:

• It opens the snooze menu for the active thread with the same presets from resolveSnoozePresets, plus the custom date option. You pick a preset with the arrow keys and Enter.
• When the thread is already snoozed, it unsnoozes the thread, the same way thread.settle restores a settled thread.
• It follows canSnooze and readEnvironmentSupportsSnooze, the same rules as the menu in useThreadActionMenu.
• Default key: mod+alt+s with when: "!terminalFocus". That key is free now and sits next to mod+shift+s for settle.

Optional

Bindable commands for single presets (for example thread.snooze.preset.1 to .N, the same as thread.jump.N). You can then snooze to "Tomorrow morning" with one key and no menu.

Related

• [Feature]: Expose more actions as bindable keybinding commands #4641: tracking issue for more bindable commands (snooze is not on its list)
• feat(web): settle and restore threads with a keyboard shortcut #8089: thread.settle shortcut, the pattern to follow
• Save custom snooze durations to the snooze menu #13881, Make the snooze presets configurable (morning hour, evening hour, quick offsets) #11399: snooze preset ideas, which the preset commands above would use

[ChristianEllehammer]

+1. A few details that might make this easier to scope, from reading the current code and docs.

Behaviour that can simply match the menu

• Running threads stay snoozable (canSnooze only blocks on a pending approval, a pending question, or a queued turn start). When one of those blocks it, the shortcut should show the same reason the menu does, not fail silently.
• After snoozing the thread you are looking at, move forward the same way the menu action already does (next remaining card, or a fresh draft if it was the last active one).
• thread.undo already reverses a snooze, so no new undo path is needed.
• On a new-thread draft there is nothing to snooze, so the command does nothing.
• when: "!terminalFocus" like thread.settle, so it still works with the cursor in the composer.

The one-press presets: key them by preset id, not by position

The optional thread.snooze.preset.1 to .N idea has a catch. resolveSnoozePresets returns a different list depending on the time: "This evening" drops out late in the day, and "Next week" collapses into "Tomorrow" on Sundays. So position 3 is "This evening" at noon and "Tomorrow" at night, and a key bound to it would snooze to different times without the user noticing.

The presets already have stable ids, so the commands could use them directly:

• thread.snooze.hour
• thread.snooze.three-hours
• thread.snooze.evening
• thread.snooze.tomorrow
• thread.snooze.next-week

If the bound preset is not on offer right now (for example evening at 22:00), do nothing and say so, instead of picking a neighbour. No default keys needed for these; only the menu-opening thread.snooze needs one.

Smallest useful version

For me the menu-opening thread.snooze alone would already solve it: one shortcut, arrow keys, Enter. The preset commands are a nice second step, not a requirement.

[jeprecated]

I have the smallest version from this thread working: an unbound thread.snooze command. It opens a picker over the existing snooze presets (arrows or Tab, then Enter), plus Custom… through the existing dialog. On a snoozed thread it wakes it instead. It reuses the existing snooze, error, and undo paths. Mobile is out of scope, the same as thread.settle.

The picker	Custom…

Would a maintainer approve this scope for a PR? Possible follow-ups, only if you want them: one command per preset, and typed times like "fri 9".

[ChristianEllehammer]

+1. This covers exactly what I asked for. The unbound command with a picker would be enough for me.

[trentonmiguez-cmd]

+1 for the smallest version: an unbound thread.snooze command that opens the existing snooze menu on the active thread. I'd bind it myself and pick the time with the arrow keys and Enter. I already settle chats from the keyboard, and snooze is the step that sends me back to the mouse.

[KyrylR]

I have the version proposed at the top of this thread working: thread.snooze, defaulting to mod+alt+s with !terminalFocus.

• One press opens the snooze options next to the open thread's row, with the soonest one focused. The digit next to an option picks it, C opens Custom…, Enter and the arrow keys work as usual, and Esc or a second press closes it.
• After snoozing, it moves on to the next thread and shows the usual undo notice, through the sidebar's existing snooze action.
• On a snoozed thread it offers only Wake now (W), so a stray press never wakes a thread on its own.
• A thread waiting on you shows the existing "waiting on you" message instead of opening the menu. On a draft it does nothing, like thread.settle.
• With several threads selected, it snoozes the selection to one time.
• The binding sits next to settle's mod+shift+s. On AltGr layouts such as Polish, where AltGr+S types a letter, the existing guard keeps typing working, and those users would rebind.

Could a maintainer approve this scope for a PR, either with the mod+alt+s default or unbound? Either is a one-line difference. jeprecated's unbound picker above covers the same ground, so I'm happy to defer to theirs if you'd rather take that one.