Supermail (part 3)

What it is

This is part 3 of the Supermail page. It carries the next stretch of the material on that page, moved here because a single page is capped at 40,000 characters.

Where to find it

Reach this part through Supermail — it lists every part and explains where the feature lives in the product. Everything below is reached from the same place.

How it behaves

Everything below is the behaviour, detail and edge cases that belong to this stretch of the Supermail page.

Feature status (Superhuman parity)

The authoritative gap analysis + per-feature status lives in src/plugins/supermail/SUPERHUMAN_PARITY.md. As of 2026-06-23 the client is at near-parity; the non-AI gaps are closed end-to-end:

• Undo send is a true deferred send — the composer sends with undoWindowSeconds, the backend holds it on a pending_sends row and fires the real sendMessage when the window elapses; Undo cancels it server-side (DELETE /messages/pending/:id).
• Search supports negated operators (-from:, -label:, -in:, -has:, -is:) end-to-end (backend query-parser → NOT clauses; frontend renders exclusion chips).
• Snippets can carry attachments (persisted in snippets.attachments_json, applied to the draft on insert).
• Follow-ups auto-resolve when a reply lands (the incremental sync calls maybeResolveOnNewMessage).
• First-run keyboard tour (features/onboarding) drills the core shortcuts; replayable from Settings → General → Personalization.
• Left-handed navigation (opt-in, OFF by default; Settings → Keyboard) — when on, W = up and S = down in the inbox list, alongside the unchanged J/K + arrow keys; because bare s is normally Star, one-key Star relocates to D, and Q is added as a left-hand alias for Label (its l still works) while the mode is on. Preference persists to supermail:left-handed-nav (features/settings/left-handed-nav-setting.ts). It is applied as an effective keymap: getEffectiveKeymap(leftHandedNav) in features/shortcuts/keymap.ts drops the bare-s Star binding and appends LEFT_HANDED_NAV_BINDINGS (w/s/d + q→label); both keymap consumers (app-shortcuts.tsx, use-inbox-actions.ts) read it so s is never bound to two actions at once. The Shortcuts drawer swaps its nav/Star/Label rows via getShortcutCatalog; the live help overlay reads the registry and already reflects it.
• Hover to act (Settings → Keyboard; ON by default) — moving the mouse onto a thread row moves the keyboard cursor to it, so the one-key shortcuts (e Done, # Trash, s Star, u Unread, h Snooze, reply/forward, …) act on the hovered conversation with no click or explicit select first. It moves the cursor + row highlight ONLY — the reading pane still opens on click / Enter, never on hover. Preference persists to supermail:hover-act (features/settings/hover-act-setting.ts); off restores hover = prefetch-only. Implemented as focusRowOnHover in features/shortcuts/hover-focus.ts, wired into all three list surfaces (inbox, label folders, snoozed) — every shortcut already targets focusManager.getFocusedId(), so moving focus is all it takes. Each page's focusManager subscriber skips its focus→reading- pane mirror for hover-driven focus via isHoverSuppressingPaneMirror(), and the existing pointerMovedTo guard keeps a row that merely scrolled under a stationary pointer from hijacking the cursor.
• Superhuman sidebar — pinned-vs-overlay nav with a hamburger drawer (auto-closes on mouse-leave) and a command-palette account selector. See "Sidebar: pinned vs overlay" above.

Still deferred (intentionally): AI (Ask/Summarize/Instant-Reply/Write), team collaboration, and live calendar — the only ⚙️ items left.

Sending from an IMAP (non-Gmail) mailbox

• A send goes out through the mailbox's own SMTP server, then a copy is filed in its Sent folder with an IMAP APPEND (backend/src/shared/mail/imap/send.ts).
• The SMTP submission names its recipients explicitly — the sender plus every To, Cc and Bcc address — because a pre-built message is never read for recipients. Until 2026-09-26 that envelope was missing, and every IMAP send failed with "No recipients defined".
• Bcc stays private. SMTP hands the submitted bytes to every recipient unchanged, so that copy is built WITHOUT its Bcc line (buildRfc822 returns both copies); the Sent-folder copy keeps it as the sender's own record.
• Gmail mailboxes do not use this path: the Gmail API gets only raw + threadId and strips Bcc itself.

Related

The overview, the other parts, and everything else worth reading next all sit on Supermail.