From 1a01efb088df07cae3f517e69940392606d00d94 Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Sun, 13 Sep 2026 18:26:47 +0200 Subject: fix(mail-overview): don't re-notify the prior batch, flatten newlines The lastmod range is inclusive at both ends and the stored revision was reused as the next start, so the batch just notified matched again. Start one revision later. A subject can contain a newline, which broke the bullet rows and the +N more count; flatten CR/LF to a space before escaping. Also reconciles the state-write comment and spec with the actual skip-and-advance failure behavior, and corrects two doc wordings. --- .../specs/2026-09-13-mail-arrival-notifications-design.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md') diff --git a/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md b/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md index 93dc13c..1423fe9 100644 --- a/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md +++ b/docs/superpowers/specs/2026-09-13-mail-arrival-notifications-design.md @@ -59,12 +59,14 @@ revision is field 3. Verified on notmuch 0.39. Per tick, if the revision has not advanced, there is nothing to do. Otherwise, per account: - notmuch count "tag:unread and tag:inbox and tag:account- and lastmod:.." + notmuch count "tag:unread and tag:inbox and tag:account- and lastmod:.." notmuch search --format=json --limit=3 --sort=newest-first "" Two calls, the same count-plus-preview pair `Accounts.qml` already makes, and only for accounts whose query is non-empty. The count gives the true N for -"+N more"; the search gives the rows. +"+N more"; the search gives the rows. The lower bound is exclusive (`prev+1`) +so the revision just written, which is inclusive at the top end, is not +re-matched on the next tick. `search --format=json` returns `authors` and `subject` directly, which is all the body needs. @@ -95,9 +97,12 @@ was down is never notified. This is the right trade: the waybar count is still correct and the drawer still shows the mail, so nothing is lost except a popup that would have been stale anyway. -The new revision is written **after** every account has been processed, so a -failure mid-loop leaves `prev` unchanged and the next tick retries rather than -dropping a batch silently. +The new revision is written **after** every account has been processed. A +single account whose count does not validate is skipped for that tick, and the +revision still advances: holding it back would make every later tick re-notify +the successful accounts' whole range. Only a failure to write the state file +itself is non-fatal and leaves the old revision, so the next tick re-notifies +rather than dropping mail. ## Accounts -- cgit v1.2.3