aboutsummaryrefslogtreecommitdiffstats
path: root/docs/superpowers/specs/2026-08-20-compose-and-send-design.md
AgeCommit message (Collapse)AuthorFilesLines
8 daysdocs: specify how a send shows progress, item 123Danilo M.1-2/+35
The spec said "disabled with a spinner" without saying where, which leaves a popup as a reasonable reading of it. A popup is wrong here: it would be modal over a window that is already disabled, and it can be dismissed while the operation continues, which is the indicator ambiguity items 18, 19, 28 and 54 each closed once. Progress goes in the composer's own status bar, through the three stages the operation actually has, since a failure filing the sent copy means something different from a failure sending. The window closing is the success message. The indicator is an indeterminate QProgressBar built inline, matching MainWindow's m_syncProgress rather than factoring out a shared widget: this codebase builds small UI inline, and two progress bars do not justify a third class. Also settles what the staged display implies for a sent-copy write that fails after a successful send: the composer still closes, because holding it open for a message already sent invites sending it twice, and the warning goes to the main window's status bar instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YDq53rMd3AQp7QmcZzpuBM
8 daysdocs: specify the composer's formatting toolbar, item 123Danilo M.1-3/+52
The spec said "the editor is plain text" and left it there, which reads as "you are on your own with the syntax". Storage format and editing affordances are separate decisions and only the first was stated. The toolbar is text transformation over the markdown source, not rich-text editing: bold, italic, code, strikethrough, link and quote, selection-aware, with the cursor landing between the tokens when there is no selection. Its shortcuts belong to the composer window's own scope and do not touch KeyMap, which matters for item 132: the two namespaces should not be conflated when that rule is revisited. Live syntax highlighting is a follow-up (item 133) rather than part of this: agreeing with the grammar about nesting and about code spans is the expensive half, and it is better judged after living with the toolbar. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YDq53rMd3AQp7QmcZzpuBM
8 daysdocs: record that cmark-gfm is stock Slackware, item 123Danilo M.1-0/+8
The spec called it a new dependency needing a SlackBuild REQUIRES entry. It is a new dependency, but /var/log/packages/ shows cmark-gfm-0.29.0.gfm.13-x86_64-3 with no _danix tag, so it is stock and REQUIRES lists only non-stock dependencies. Also records the staleness cost accepted with it: cmark-gfm tracks an older CommonMark base (0.29 era) than the stock plain cmark (0.31.2). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YDq53rMd3AQp7QmcZzpuBM
8 daysdocs: specify compose and send, item 123Danilo M.1-0/+537
Brainstormed with the user. Design only, no code, which is what the item's #plan-only tag asked for. The decision that shaped everything: there is no MTA on the machine, so "an external script on the same model as mailsync.sh" had no model to copy. Send becomes a per-account send_command taking the message on stdin, exactly as [sync] command already works, which keeps the no-network-protocol rule intact without naming an MTA. An account with no send_command is receive-only by construction, which is how one of the five accounts is meant to work. Reply, reply-all and forward are disabled on its mail behind a ribbon that says why. The body is markdown parsed by cmark-gfm rather than a hand-written parser for a limited set: the two share no code, so the small one is deleted wholesale the moment the set widens. Four new units, three of them widget-free and testable without a painter. MessageSender is deliberately a separate unit rather than a method on the composer, so a future outbox wraps the funnel instead of reworking it. Item 123's section is replaced by a pointer to the spec, per this document's own rule for a fully specified item. The brainstorm opened items 128 to 132, including a review of the every-action-has-a-shortcut rule, which the user raised: six more actions takes it past the point where a chord for everything is useful. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01YDq53rMd3AQp7QmcZzpuBM