From 9c782e0c96c19525babc6c7ceb4f1a184a400169 Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Wed, 26 Aug 2026 20:17:50 +0200 Subject: docs: record item 119 and close it in the backlog The status rows for 119 and its duplicate 146, 119's section moved to the closed file on this commit rather than left for a later cleanup, and the README and changelog entries for the feature. CLAUDE.md gains three findings, all of which cost time to learn here: A defensive counter for an unreachable case is worse than nothing, because it blocks the feature that needs the data. Reading the code said that branch was reachable and the reading was wrong; instrumenting it and running the suite is what settled it, and the tests that appeared to exercise it were driving it from outside the production path. PendingChangesDialog groups by a run rather than a map, which is why the snapshot is stable-sorted, and startsMessage is carried rather than inferred so a stale row still opens its own run. A queued call carrying a container deserves the same suspicion as a Q_ENUM, with the measurement: both containers cross intact on Qt 6.11, but a standalone probe found QMetaType::fromName("QList") invalid while QList resolved, so the property does not follow from the type. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01P88Q3MCSCSQxKDy7pmXh9F --- README.md | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'README.md') diff --git a/README.md b/README.md index 70df5ca..4ae0034 100644 --- a/README.md +++ b/README.md @@ -691,6 +691,17 @@ that a sync has not yet carried over, and clears the count when one succeeds. A **failed** sync leaves the count standing, since the changes really are still unsynced. +**Click the count to see what it holds.** The list names each message with +the actions waiting on it beneath it, so a message you tagged twice appears +once with both. An action taken on a whole thread is one entry, saying how +many messages it covers, because that is what you asked for; an action on a +single message names that message, whether or not it sits in a thread. + +The list is read-only, and it is a snapshot taken when you open it: it does +not rewrite itself while you read it. A change whose message has since left +the index is still listed, saying so, rather than quietly disappearing, so +the number you clicked always matches the number of entries you get. + The count is a lower bound rather than a guarantee: an external `notmuch new` from your own cron can carry changes over without this application noticing. -- cgit v1.2.3