From 1a6007b4cdaacb22d013daeb58deb6ae72afda07 Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Fri, 7 Aug 2026 11:08:54 +0200 Subject: docs: record how to find the messages item 41 affected Confirmed on real mail: a message whose text/html part carries a Content-Id now renders. Item 41's status drops the caveat about the reported message not being relocated. Finding an affected message is harder than it looks, which is why the search is worth recording rather than rederiving. A Content-Id on an inline image is the common case and always worked, so a plain grep for the header returns mostly noise. The narrow case is a Content-Id in the same header block as a text/html Content-Type, which needs a small awk pass over the message files. That found 96 in one inbox, all bulk senders. Also records that file: is not a notmuch search term, so a matched path cannot be turned into a query directly; the Message-ID header is the way across to an id: query. Co-Authored-By: Claude Opus 5 --- .../plans/2026-08-03-post-0.1.0-usability.md | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) (limited to 'docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md') diff --git a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md index d4465ce..d98c91e 100644 --- a/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md +++ b/docs/superpowers/plans/2026-08-03-post-0.1.0-usability.md @@ -88,7 +88,7 @@ taking that too literally. | 38 | `test_mainwindow` fails when a real sync holds the lock | testing | XS | **done** | | 39 | Thread list cannot be sorted by clicking a column header | workflow | S | open | | 40 | No live filter over the current view | workflow | M | open | -| 41 | A message whose HTML body carries a `Content-Id` renders blank | correctness | S | **done** (fixture-verified; the reported message was not relocated) | +| 41 | A message whose HTML body carries a `Content-Id` renders blank | correctness | S | **done** | | 42 | "Syncing..." says nothing about what is being synced | feedback | S | open | | 43 | No "Mark all read" for the current view | workflow | S | open | | 44 | No way to manage the filters applied at sync time | workflow | ? | open, unspecified | @@ -2062,6 +2062,26 @@ The two are independent, and the current code treats them as exclusive. item 15's namespacing is unaffected, which the existing mimeparser tests already cover. +**Confirmed on real mail (2026-08-07).** Affected messages are not easy to find, +because the common case, a `Content-Id` on an inline image, always worked and +swamps a naive grep. The narrow case is a `Content-Id` in the *same header +block* as a `Content-Type: text/html`: + +```bash +notmuch search --output=files 'tag:inbox' | while read -r f; do + awk 'BEGIN { IGNORECASE=1; html=0; cid=0 } + /^$/ { if (html && cid) { print "yes"; exit }; html=0; cid=0; next } + /^Content-Type:[ \t]*text\/html/ { html=1; next } + /^Content-ID:/ { cid=1; next } + END { if (html && cid) print "yes" }' "$f" | grep -q yes && printf '%s\n' "$f" +done +``` + +That found 96 messages in one inbox, all from bulk senders, with 57 from a +single one. Pull `Message-ID` from a match and paste it into the query bar as +`id:` to open it. Note `file:` is **not** a notmuch search term, so a +path cannot be turned into a query directly; read the header instead. + ## 42. "Syncing..." says nothing about what is being synced **Observed (user, 2026-08-05):** the only feedback during a manual sync is -- cgit v1.2.3