| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Restore moved the file back to the inbox folder and left it invisible: the
message carried no `inbox` tag, so the Inbox view could not see it, and the
user reported restoring a message and losing it.
Delete strips `inbox` so a deleted message leaves that view, which makes
restoring it the other half of the same change. restoreResolvedMessages()
already meant to add the tag back, and the comment above the branch
describes exactly this failure, but the comparison deciding it read
`origin`, which four lines earlier had been reassigned from the bare folder
name to the finished tag. `deleted-from:Inbox` never equals `Inbox` however
an account spells its inbox, so the branch was dead and the tag never came
back.
The destination folder is taken from the move's own key instead, which is
what the surrounding code already builds and what the comment says is being
compared.
The existing test passed against this throughout. It asserted the file
moved, the origin tag came off and `deleted` came off, all of which were
true; nothing asserted the tag that decides whether the user can see the
message afterwards. It does now, and fails against the old comparison.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P88Q3MCSCSQxKDy7pmXh9F
|
|
Hand-testing item 169 found four defects, three of them visible on every
card.
The initials were taken from whatever the card's first line held, which is
the raw From header on a reply row and notmuch's comma-joined author
summary on a thread row. A naive space split therefore gave `T<` for
`tsujan <notifications@github.com>` and one letter each from two different
people for `Standreas, tsujan`, and a separator counted as a word, so
`INE - Expert IT Training` drew `I-`. Avatar::initialsFor() now normalises
first: the angle-addr and any quoting go, a comma takes the first entry
unless the name is quoted, a bare address is not a name, and a word has to
carry a letter or a digit. Avatar::fillFor() uses the same normalisation,
so an address in the name's place no longer reads as a person.
The two-tone fill built its gradient axis as a radius from the centre, so
the 0.5 colour stop landed on the squircle's edge and one hue filled almost
the whole face. The axis spans the diameter now.
The fade ran left to right, which put its hard stop at 60% of the card and
read as a slab rather than a wash. It runs right to left: opaque at the
card's right edge, where the only hard stop is the card's own boundary, and
gone before it reaches the accent bar that already states the account.
And the flat views hashed the user's own address on every row, so every
Sent and Drafts card shared one pattern. ThreadSummary::firstMessageRecipient
rides the recipient fold, which already parses the To header, and
SenderAddressRole prefers it, falling back to the sender when there is no
usable To.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01P88Q3MCSCSQxKDy7pmXh9F
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
A week-long scope is right once the list is in use and wrong on the first
run, when it proposes almost nothing and leaves the file taking months to
become useful. BusinessSenders::scanQuery() returns "*" while the file
holds no active entry and date:1week.. afterwards.
A file holding only rejected candidates counts as unused, which costs one
more full scan and re-proposes nothing, since appendCandidates already
skips every address the file mentions in any form.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LXCZFLXbAii5n5wtovpdhh
|
|
Fourteen tasks against the item 169 spec, TDD throughout. Two new
namespaces of free functions over values, Avatar and BusinessSenders, so
the initials, the fill choice and the list parsing are all assertable
without a painter or a widget.
The plan records where the existing traps apply rather than leaving them
to be rediscovered: the two separate switches in data(), the inclusive
QRect::right(), the queued-connection metatype registration, and the
rule that a count request must not bump the query generation.
Task 14 is the hand-off: this item is judged by looking, so the plan
names the five things to look at and the constants most likely to move.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LXCZFLXbAii5n5wtovpdhh
|
|
Reconciliation against the user's notes found two unrecorded lines, and
corrected the cause of one entry that was recorded wrongly.
- 169, new: a card shows the account only as a bar, with no fade and no
avatar. Half of it shipped as the accent bar.
- 170, new: a row that stops matching the view only leaves it on the
Delete path. Filed from a note that reads as a stale request for
optimistic updates; it is not. removeThreadsWithoutTag() has exactly
one caller, so marking a message read in the Unread view repaints the
row and leaves it in a list it no longer belongs to.
- 65, narrowed: the notes now name it as a dead-code and duplication
sweep rather than a performance or security pass, so it produces a
list to decide on rather than a diff.
The spec for 169 covers the avatar geometry, the fade, the two
hash-generated fills and the sender list that chooses between them. It
also records the one structural change the feature needs and the
measurement that forced it: ThreadSummary::authors carries display names
only, with no address anywhere, so the identicon has nothing stable to
hash and the sender list has nothing to match. ThreadSummary gains
firstMessageSender, filled by the walk that already fills firstMessageId.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LXCZFLXbAii5n5wtovpdhh
|
|
Item 68, which turned out to be three things once its premise was
measured. The note asked to extend a "passed" subject rule to "Fw:";
there was no subject rule, and the correlation it rested on did not
exist. What did exist was a gap nobody had reported.
Reply and forward now flag their source. The Maildir R and P flags,
which every other client sets and notmuch reads back as "replied" and
"passed", had never been written here: measured on the developer's
index, all 317 "replied" and all 6 "passed" came from other clients.
ComposeWindow emits sourceMessageAnswered after a successful send and
MainWindow routes it through sendMessageTagChange, message-scoped and
off the undo stack, for the reason auto mark-read is: the flag records
that the mail went, and the send cannot be undone.
ComposeContext carries sourceMessageId rather than reusing inReplyTo,
which is deliberately empty on a forward so the recipient's client does
not file it under the thread it left. Keying on it made the "passed"
half dead code that compiled and never fired. A resumed draft is
excluded: its kind records how the file was opened, not what the user is
doing, so flagging on it would set R from a guess.
A received forward gets its own mark. Derived from the subject at paint
time, storing nothing and reaching no server, because "passed" means "I
forwarded this" and setting it from a guess would assert something false
on 222 existing messages. subjectIsForwarded() shares forwardSubject()'s
prefix table so the two cannot disagree, strips a Re: chain first, and
takes extra locale spellings from [general] forward_prefixes, which
extends the built-in table rather than replacing it.
A mutation survived the first round and corrected a claim in the code:
QRegularExpression::escape already makes a punctuation prefix inert, so
the word guard is not about pattern validity. It stops a configured "-"
matching "-: x". The comment and test say that now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LXCZFLXbAii5n5wtovpdhh
|
|
Six entries under Unreleased, covering items 104, 112, 118, 166, 167 and
168. The two fixes are worth a user reading them: one made the
application look like it had stopped syncing, and the other lost mail
from the account that received it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
Item 168, found by the user while hand-testing 118: Delete could be
triggered on a message already in the trash. Not dangerous, which is how
it survived. moveMessages() finds the file already in the destination
and takes its early-return branch, so the message is reported as moved,
an unsynced change is counted, and nothing happened. Restore had the
mirror of the same problem, added unconditionally to both menus and so
offered on mail that was never deleted.
Each is now hidden where it has no meaning, which is the rule item 112
established for the unread entry. The question is about the PATH, never
the deleted tag: a message trashed by another client carries no such
tag, which is why the trash view is path-based, and asking the tag would
hide Delete on exactly the mail a trash view is full of.
Delete also removes unread now, at the user's request on the same
tangent. It travels inside the same sendMove() call rather than as a
second write, so one undo returns the folder and the tag together. This
rewrites the Maildir filename, because maildir.synchronize_flags is
true, and so reaches the server: the same mechanism the post-new hook
refuses to touch, and the difference is that the hook acts unattended on
arriving mail while this is an explicit gesture on a message in front of
the user.
A mutation survived the first round and found a real hole: comparing the
prefix without its trailing separator passed every test, because no
fixture had a folder whose name starts with the trash folder's. Under it
Delete silently vanished from mail in acct/trash-old, which is not the
trash. The fixture carries that row now and all three properties are
mutation-checked. The suite is 37 of 38, the failure being item 136 on
an unrelated path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
Item 118, unblocked by 103. Message > Empty trash..., scoped to the
account selector, with no default shortcut.
purgeMessages() is a separate worker entry point from moveMessages()
rather than a flag on it, because the two look alike and only one can be
undone. It takes named ids, never a folder sweep, so the blast radius is
what the dialog enumerated and the user confirmed, and it deletes every
file of a message: notmuch deduplicates by Message-ID, so leaving one
behind leaves the message alive in the folder the user emptied.
It confirms, naming the count and the account, defaulting to Cancel.
That breaks CLAUDE.md's no-confirmation rule deliberately and the rule
now records it as its single exception, in the same paragraph: a purge
has no inverse to push onto the undo stack, so the protection the rule
provides has to come from somewhere, and the dialog is where.
Two defects found rather than reasoned. The count claimed messages whose
files were already gone, overstating an irreversible action; an absent
file is correctly not an error, but that is not the same as destroyed.
And the user's hand test found the list still showing mail that no
longer existed: a purge removes rows rather than changing them, so there
is no optimistic update to apply and nothing was connected to
messagesPurged at all. It re-runs the current query now.
Verified against the live index after the user emptied one real
account's trash: zero files on disk, zero in the index. The suite is 37
of 38, the failure being item 136 on an unrelated path. Ten new strings
translated, lrelease reports 0 unfinished.
Item 168 is filed from the same hand test, on Delete being offered on
mail already in the trash.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
Item 112, and 99 and 147 with it: the user's note is one design across
all three. A union is not a state. ThreadSummary::tags is notmuch's
union over the conversation, so a thread holding even one unread message
answered "unread" and the thread toggle always chose "mark read". There
was no input that reached "mark thread unread" on a mixed thread, which
is the thread a user wants it for.
The thread toggle becomes two absolute actions, mark_thread_read and
mark_thread_unread. Neither takes a default chord, at the user's choice:
Ctrl+Alt+U meant whichever direction the union picked, and since item
132 a shortcut is a chosen subset rather than a requirement. It is now
unbound.
The message-scoped toggle stays a toggle, because one message has a real
two-valued state, and its label now names the direction it will go. On a
selection with no single state the entry is hidden rather than labelled
wrongly, chosen over disabling it; the thread submenu is the route then,
and its entries are absolute.
selectionTagPresence() is the three-valued predicate that needed to
exist. everySelectedRowHasTag() delegates to it and keeps its two-valued
answer, which is all a direction needs; a label needs the third value.
The refresh is keyed on the model's dataChanged as well as on the
selection, so a write moves the label without reselecting and none of
the six optimistic-update call sites has to remember.
Three mutations fail: restoring the union predicate reports the user's
original symptom, showing the action on a mixed selection, and dropping
the dataChanged refresh. The suite is 37 of 38, the failure being item
136 on an unrelated path. Four new strings translated, lrelease reports
0 unfinished.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
The fix landed in 6ea6980 and the row was left open. Its section moves to
the closed file with what the fix turned out to need: the loop, the two
query forms that were measured and rejected, the split-index fixture,
and the live read-only verification.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
The version alone cannot tell one build of an unreleased X.Y.Z from
another, and the user rebuilds and hand-tests unreleased builds daily.
They chose a counter over a git description: what they want to know is
that the binary is newer than the one they were running, not which
commit it came from.
QTMAILDIR_BUILD_NUMBER is a cmake option, ON by default, that runs
cmake/BuildNumber.cmake as a build step to increment a counter and write
buildnumber.h. It had to be a build step: configure_file runs once per
cmake run, so a counter interpolated into version.h.in would sit still
across exactly the rebuilds this exists to distinguish, which is why
version.h.in includes a second generated header rather than carrying the
number itself.
Two macros, and the split is load-bearing. QTMAILDIR_VERSION stays a
clean X.Y.Z and keeps the window title, applicationVersion and anything
that might ever compare versions; QTMAILDIR_VERSION_DISPLAY carries the
number and goes to the three surfaces the user picked, --version and
--help, the About dialog, and the placeholder pane. The window title was
offered and declined, since the number would then be in every
screenshot.
The counter lives in the build directory and is not tracked, so it
cannot conflict on a pull or leave the tree dirty; a fresh build
directory restarts at 1, which is honest, because it is a different
build tree. A release passes -DQTMAILDIR_BUILD_NUMBER=OFF and the header
is written empty. The SlackBuild in the my-slackbuilds repo needs that
flag and is a separate commit there.
Verified by running it, since none of this is reachable from a C++ test:
three consecutive builds reported build 2, 3 and 4, and a separate
Release configure with the option OFF reported a clean 0.27.0. Passing
the flag to a tree that does not have the option yet is an unused-cli
warning and exit 0, so the SlackBuild change is safe before 0.28.0
ships. The suite is 37 of 38, the one failure being item 136 on an
unrelated path.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
notmuch deduplicates by Message-ID, so mail the user sends to another of
their own accounts is one message with two files: the sender's Sent copy
and the recipient's Inbox copy. The carve-out matched on a file's path
and tagged the message, so matching the Sent copy stripped inbox from
the copy that had genuinely arrived and the mail was missing from the
account that received it.
sent_only() keeps a message only when EVERY file is inside a sent
folder, which is what the docstring already claimed the predicate did.
It is a loop because no query can express it: measured against a
two-file message, `not path:` does not exclude it, and `count
--output=files` reports every file of every matching message rather
than the files that matched. Both read as if they worked, and are wrong
for the same reason, that a notmuch term is a predicate over a message
while this distinction is between its files.
The root comes from database.mail_root rather than database.path, since
this index is split and no message file is under the index directory. A
test fixture with the index outside the mail root covers it; the
ordinary layout cannot, because both keys return the same string there.
Both mutations fail: all->any loses inbox on the self-addressed message,
mail_root->path silently stops stripping anything. Verified read-only
against the live index, tagging nothing: of 807 messages matching a sent
path, 780 are still stripped and 27 are spared, every one of them two
files with one in another account's inbox. No arrival is affected.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
The user has not run mailctl in months and the coupling this document
described is gone: the live database.hook_dir symlinks post-new,
mailrules.py and qtmaildirconf.py into assets/hooks/ here, where their
three suites also live. All three pass.
The format discipline survives the move and is kept, because what makes
it necessary is two independent readers of one file, not two
repositories: src/tagrules.cpp and assets/hooks/mailrules.py still share
no code and still agree by test. What changes is the procedure around
it, which no longer sends anyone to a sibling checkout, and the round
trip, which is now verified by running the hook rather than by a CLI
that is retired.
Item 166 said the same thing and was filed a day before this was
noticed; its row and its two-repo constraint are corrected with it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
The reconciliation against the user's own notes found one entry with no
item here: a dev build number, so a rebuilt binary can be told from the
one it replaced. Verified in the code rather than copied from the note.
`src/version.h.in` interpolates PROJECT_VERSION alone, which moves only
when the release procedure bumps it, and the user hand-tests unreleased
builds daily.
It needs a decision before any code. A git description is accurate and
costs a configure-time dependency that is easy to ship wrong; a counter
always moves and identifies nothing. Either way a release build must
keep printing a clean X.Y.Z, since the SlackBuild builds from a tarball
with no git checkout.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
The fix landed in b1db3e8 and the row said "awaiting hand test". A sync
run from the application added 20 messages and they appeared without a
restart, which is the property the reopened read-only handle exists to
give, so the row is now done and the section moves to the closed file.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HFuRPtzFrSxCQjFk6tq7gD
|
|
Item 104 is fixed and its entry was wrong. It named mbsync's folder
patterns as the leading theory and concluded the cause was most likely
outside this repository; the reproduction put it at layer 3, in the
worker's own handle. The superseded theory is kept, since it would
produce a similar symptom and remains worth checking first in any future
report of this shape.
Two measurement errors from the diagnosis are recorded with it. A bare
`inbox` in a notmuch query is a free-text term rather than a tag term,
and the application generates `tag:inbox`; reading a message's tags
across every file matching a subject mixes several accounts' copies into
one answer. Each produced a confident wrong answer before it was caught.
Item 166 is new, found while setting up msmtp. The `post-new` hook's
sent-folder carve-out judges provenance by a file's path, but notmuch
deduplicates by Message-ID, so mail sent between two of the user's own
accounts is one message with a file in each. The carve-out matches the
sent copy and strips `inbox` from the message the recipient's inbox copy
also belongs to. Three options are laid out; the fix is a two-repo
change and the hook runs unattended on live mail, so it needs a decision
rather than a patch.
|
|
A read-only notmuch handle is a Xapian snapshot taken when it is opened,
so it never observes a write made by another process afterwards. The
worker opened one handle and kept it for the process lifetime, which made
the sync script's `notmuch new` invisible: every query after startup was
answered from the index as it stood when the application launched.
The symptom was mail arriving while the window was open and not appearing
until a restart. It was not confined to the post-sync refresh, which is
what made it hard to place: a query typed by hand also found nothing,
since it hits the same handle. Tag writes were unaffected throughout,
because applyTags opens its own read-write handle per call.
Reopen in openReadOnly() rather than at each call site: every read path
begins by asking for the handle. A reopen failure is deliberately not
fatal, since the existing handle is still usable and answering from a
slightly stale index beats refusing to answer.
The suite could not reproduce this before: the test helper builds a fresh
worker per query, so it opens a fresh handle every time. The new test
holds one worker across two queries and indexes between them from a
second process.
Item 104.
|
|
Found while hand-testing items 163 and 164: four saves produced four
distinct ids, and one reopen-and-edit turned one into another.
Cause verified in the code rather than inferred. MessageBuilder::build()
calls g_mime_utils_generate_message_id() unconditionally and every
autosave calls build(); OutgoingMessage has no field to carry an id in,
and ComposeContext has none for the draft's own id either, since
inReplyTo and references are the ORIGINAL's when replying. So a stable
id needs a field threaded from forDraft() through both structs, not a
changed call site.
Filed as needing a DECISION rather than an implementation, because what
a draft's identity is is not obvious: a stable id reused at send makes
the draft and the sent message one message but means the server saw that
id before anything was sent; a stable id discarded at send keeps
revisions collapsed while drafting and threads under a fresh one; the
status quo never reuses an id for two different things, which is its one
real virtue.
Not urgent and explicitly not blocking item 163, whose fix restores
correct file replacement. This is the property that turned that fork
into two MESSAGES rather than one duplicated file, and the remaining
route to it is an interrupted save, since DraftStore::write() unlinks
the previous revision only after the new one is safely on disk.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Its section moves to the closed file on this commit, with the outcome
recorded: MaildirName::resolveRenamed() wired into all three read sites,
the two deliberate refusals (ambiguous match, genuinely missing file)
and why each has a test, and the note that forDraft() must seed
draftPath from the resolved path or the fork simply arrives one step
later.
The stable-Message-ID question is recorded as left undecided rather than
quietly dropped: it is what turns a stale path into two server-side
messages rather than one replaced file, and a draft's id is not yet the
sent message's id, so it wants its own item.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Item 163. mbsync renames an uploaded file to add its `,U=<uid>` infix,
and the model's `MessageRef::filePath` was captured when the query ran,
so a row loaded before that sync names a file that no longer exists.
MimeParser then honestly reports a message it cannot open.
MaildirName::resolveRenamed() answers the filesystem question: returns
the path unchanged when it still exists, otherwise looks in that one
directory for the file whose unique stem matches. mbsync preserves the
stem (`<stem>:2,D` becomes `<stem>,U=5:2,D`), which is what makes this
safe to do by filename at all. It never recurses, never crosses a folder
boundary, and refuses an ambiguous match rather than guessing, since
opening or moving the wrong message is worse than reporting none.
It lives in MaildirName because that namespace already owns the `,U=`
infix and is a pure-value unit testable without a widget. A file that
changed FOLDERS is a different question that only the message id can
answer, and NotmuchWorker::moveMessages() re-resolves that way already.
Three call sites, all of which held a stale path:
- The message pane, which reported "(unreadable message)" over a file
that was on disk and readable. Cosmetic and self-repairing.
- Reply and Forward, refused outright, so the user could not answer a
message that was sitting there.
- The draft reopen, and this is the half that costs data. The refusal
happens BEFORE any composer exists, so the user composes again into a
fresh window whose autosave has no previous path to unlink. The old
revision survives, each save mints a new Message-ID, and both files
reach the server. The unlink machinery was correct throughout and
never ran.
forDraft() seeds draftPath from the RESOLVED path, never the caller's:
seeding the stale one would let the reopen succeed and the unlink still
miss, which is the same fork arriving one step later.
Covered by five unit tests on the resolver, including the two that keep
it honest (a genuinely missing file yields nothing, and a neighbouring
message is never matched), and by an integration test that renames the
draft the way mbsync does and asserts the file COUNT, which is the shape
the fork actually takes. Both mutation-checked; the integration test
fails with the reported symptom when the resolution is removed.
The stable-Message-ID question is deliberately untouched: it is what
turns a stale path into two server-side messages rather than one
replaced file, and it wants its own item.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Item 162 is done and its section moves to the closed file on this
commit, with the outcome recorded on it: moveMessages() re-resolves by
message id when the recorded path is gone, and the hold candidate was
investigated and rejected because aSyncHoldsTheWriteLock() guards
notmuch's lock while the window sits between mbsync's rename and that
sync's notmuch new.
Item 163 gains a second site, found while hand-testing 164 and worse
than the one it was filed for. openComposerFor() passes ref.filePath to
forDraft(); after mbsync renames the file the parse fails and the reopen
is refused BEFORE any composer exists, so composing again starts fresh
with no previous path to unlink. The old revision survives, each save
mints a new Message-ID, and both revisions reach the server. The unlink
machinery is entirely correct and never runs. Its heading and row now
name both sites, and the note that 162's fix would cover it is removed:
that fix re-resolves inside the worker, while these hold a stale path in
the UI.
Item 164 gains the reproducer's findings. Seven variants in throwaway
databases establish that index_file applies no tags, that the carve-out
strips inbox correctly in every filename shape and ordering tried, and
that the only reproduction is a pass applying inbox while tag:new is
already spent. The trigger is still not established, and the entry says
so: the live log shows the hook ran on the affected pass and logged
success, which the new match-count instrumentation will disambiguate on
the next occurrence.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Item 164 diagnostics. A `notmuch tag` that matches nothing succeeds, so
the carve-out logged "applied over N folder(s)" whether it stripped
`inbox` from four messages or from none. A draft kept `inbox` on a pass
whose log claimed the carve-out had run, and that line could not tell
the two cases apart.
Count before tagging, since the tag is what makes the count zero, and
report it alongside the folder count. Nothing branches on the value: a
failed count yields `?` rather than failing the sync, because the tag
reports its own status separately.
This does not fix item 164, whose trigger is still unreproduced. It
makes the next occurrence self-explaining: `0 message(s)` means the
message was never in tag:new scope, and a non-zero count means the tag
ran over it and something re-added the tag afterwards.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Item 162. mbsync uploads a file and renames it to record the server UID
(`<name>,U=<uid>:2,<flags>`), and notmuch keeps the pre-`U=` name until
that sync's `notmuch new` runs. moveMessages() renamed a path that no
longer existed, reported "Cannot move <file> to <folder>", and skipped
the message: Delete silently did nothing while blaming the destination
folder for a timing problem.
Before renaming, check whether the recorded path still exists. If it
does not, reindex that one Maildir directory and re-read the message's
filenames by id, taking the one that is on disk.
Recovery is by MESSAGE ID rather than by scanning the folder, because
two files can carry the same id and scanning could move the wrong one.
reindexFolder() indexes a single directory and is deliberately not a
`notmuch new`, which would walk the whole Maildir and run the post-new
hook that tags real mail.
Bounded to one reindex and one retry, so a file that is genuinely gone
still reports rather than becoming a silent no-op. The second test pins
that half.
Holding the move while a sync runs was the other candidate and is not
the fix: sendMove() already refuses on the write lock (items 97 and
106), but aSyncHoldsTheWriteLock() tracks notmuch's lock, while this
window sits between mbsync's rename and that sync's `notmuch new`.
mbsync renames without touching that lock, so the damaging window is
open when there is nothing to observe. That refusal is left alone; it
does its own job.
The ordinary fixture layout cannot see this, since nothing renames a
file underneath the index. The test renames without reindexing, which
is exactly the window mbsync opens, and guards that the database still
names the old path so it cannot pass against a fixture that quietly
reindexed. Mutation-checked: disabling the recovery reproduces the
original error.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
The entry blamed a missing drafts helper. Neither half of that was true.
NOT_ARRIVALS in qtmaildirconf.py is ("sent", "drafts"), so sent_folders()
already returns both; the function name says sent and its contents do not,
which is what made the wrong reading plausible. Run against the real
config it returns every account's drafts folder, and notmuch count over
the carve-out query and the affected message id returns 1: the query the
hook builds MATCHES the draft. The folder list and the query are correct
and the fix is not there.
A second theory is also recorded as dead. An mbsync-style rename does not
re-apply new.tags: measured in a throwaway database, a file renamed to add
,U=4 and reindexed kept the tags it had.
What is established: the carve-out is scoped to tag:new, the draft carries
inbox, and tag:new is 0, so it was never in scope when the hook ran. The
installed hooks are symlinks into this repository, verified rather than
assumed, so the code read is the code that runs.
What is not established is which pass tagged the file. The likely shape is
an ordering one, since item 158 indexes a draft from the application
itself and a file already known to the database is not new on the next
pass, but that is a third hypothesis and the first two were both wrong.
The entry now calls for a reproducer driving the real sequence before any
code is written, since the hook tags real mail unattended every ten
minutes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
163: the message pane names a path that no longer exists and reports the
message unreadable. Same mechanism as 162, different site and different
fix. mbsync renames the file to add ,U=<uid>; by the time the pane fails,
notmuch is already CORRECT and the stale path is the MODEL's, cached when
the row was loaded. Measured: the index named the ,U=4 file while the
pane named the pre-U= one. 162's likely fix, refusing to write while a
sync runs, does not touch the read path. Points at recovering by
re-resolving the id, the way recoverStaleThread() already does, with a
bounded retry so a genuinely unparseable message still reports.
164: every newly synced draft carries inbox. Measured "draft inbox
unread" on a draft this application wrote. strip_inbox_from_sent() reads
qtmaildirconf.sent_folders() only, and qtmaildirconf.py has no drafts
equivalent, so the carve-out never covers a drafts folder. Item 158's
measurement was right and did not reach this: index_file assigns no tags,
but mbsync's upload and the next notmuch new re-tag the file.
164 also contradicts the shipped 0.27.0 changelog, which claims sent mail
and drafts both stay out of the inbox. The drafts half has never been
true, so correcting the entry is part of that item.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Found by hand while deleting a draft: "Cannot move <file> to <folder>".
Neither Delete nor item 158 is at fault. mbsync uploads a saved draft and
RENAMES it to add its ,U=<uid> infix, and notmuch keeps the pre-U= name
until that sync's notmuch new runs, so moveMessages() calls QFile::rename
on a path that no longer exists.
Verified against the live Maildir rather than read: notmuch named a file
that was not on disk while a sync was running, and the same query was
clean afterwards with the file present under its new name. That is why it
reads as intermittent and why it heals itself.
Truthful and lossless, but the action silently does nothing and the
message blames a folder for a timing problem, which sent the user looking
at a configuration that was correct.
Records both candidate approaches and notes the likelier one: refuse the
move while a sync holds the lock, joining the held-edit machinery items
97 and 106 already built for exactly this shape, rather than re-resolving
the filename and racing the same window. Also notes that this is the ,U=
trap CLAUDE.md records for MaildirName::fresh(), seen from the other
side.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
File, Edit and Format, to the scope the user chose. Save draft (Ctrl+S)
is the only new action: saveDraftNow() was reachable from the autosave
timer, the send path and closeEvent, so there was no way for the user to
ask for a save. It routes through that same function, which is what
emits draftSaved for item 158's indexing, reports through item 160's
status bar and raises the failure banner; a second write path would have
to repeat all three.
The menus show the toolbar's own QAction objects rather than copies, as
item 140 required for the message pane's bar. Two needed hand-building.
The HTML toggle is a QToolButton and cannot go in a menu, so a checkable
twin mirrors it in both directions, since a menu entry that only follows
the button is half a control. The signature entry takes the switch's own
QMenu pointer, because that menu is rebuilt whenever the signatures
change and copied entries would go stale.
Edit's entries drive QPlainTextEdit and follow its own undoAvailable and
copyAvailable, so a greyed entry tells the truth about what pressing it
would do.
theMenuBarReachesEveryComposerAction() is item 132's reachability rule
applied to the composer: it walks the real menu bar and collects the
composer's actions with findChildren, so an action added to the toolbar
and forgotten in the menus fails without the test being touched. It
skips actions owning a submenu, since Qt emits no triggered for those.
The composer's actions stay out of KeyMap, per item 148: they are
parented to this window, so they are WindowShortcuts dispatched to the
active composer and the main window's namespace is untouched.
lrelease reports 496 finished, 0 unfinished.
Closes item 161.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Autosave worked and said nothing on success. The only feedback was
m_banner, which is the failure channel and whose persistence is
load-bearing for the quit path, so success got its own channel rather
than sharing one.
The fix is a funnel, not a label. m_dirty had seven writers, four of
which clear it and only two of those are a save: the constructor clears
it because seeding is not an edit, and the send handler clears it
because the message is gone. A cue hung off saveDraftNow() would have
been silently wrong in both. setDirty() is the only writer now, and it
refreshes the status cue and setWindowModified() together so neither
display can drift from the flag.
The age line needs a tick of its own, since it moves with no edit to
drive it. Five seconds against a label that reads in tens of them.
Two defects found by probing rather than by reading. The %n plural
rendered as "2 minute(s) ago" for every English user, because Qt picks a
plural form only when a translation supplies the forms and there is no
English .ts; it uses %1 and "min" now, which Italian substitutes
identically. And the status mark was inside the translatable string,
where a translator could drop it; it is concatenated outside tr().
Presentation reworked after the user looked at it. The first version
reused item 151's yellow ribbon treatment, which reads as a misplaced
widget on a bare status label rather than as a warning, and put both
labels in the permanent widget area, which is the right-hand tray. They
are ordinary status text on the left now.
onlyTheSetterWritesTheDirtyFlag() asserts the funnel structurally, by
reading composewindow.cpp: the first test for the send path called
markClean() directly and a mutation restoring a direct assignment left
the whole suite green. Four mutations now fail. The suite still cannot
see the presentation, which is why that half needed a hand test.
lrelease reports 487 finished, 0 unfinished.
Closes item 160, and unblocks 161.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Both are composer feedback, and both causes are verified in the code
rather than copied from the note.
160: autosave works and is silent on success. The only feedback is the
failure banner, whose comment explicitly rejected the fading status line
that success actually wants. m_dirty and the draftSaved signal already
carry both states; nothing displays them.
161: the composer has no menu bar, and Save draft does not exist as an
action at all. saveDraftNow() is reachable only from the timer, Send and
closeEvent, so there is no way for the user to ask for a save. Notes that
the composer's actions stay out of KeyMap per item 148, that
everyActionIsReachableFromAMenu() walks the main window only, and that
"duplicate the other actions" needs the user to say which, since most
message actions are meaningless over a message being written.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
Signatures (item 152): one markdown file per signature under
~/.config/qtmaildir/signatures/, spliced into the composer buffer and
chosen from a switch on the editor bar. [compose] signature seeds a new
message, [account.<key>] signature overrides per account, and
[compose] signature_position picks end or above_quote.
Also carries three fixes found by hand-testing it: a saved draft is
indexed so it appears without a sync (item 158), the Drafts filter lists
messages rather than threads so a draft reply can be opened (item 159),
and a resumed draft no longer re-seeds its signature on a From: change.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
The Drafts filter shipped threaded in item 138, reasoning that a draft
reply belongs with the conversation it answers. That reasoning cost the
feature: a thread row stands for its first matched message, which for a
draft reply is the message being replied to, so the draft itself had no
row of its own and double-clicking the conversation opened nothing.
Reversed with the user. Drafts now follows Sent; Trash deliberately does
not, since a deleted message still belongs to its conversation and
nothing there has to be reachable for editing.
The view mode was decided in three places that each compared against
"sent" and had to agree: builtinFilter(), the reader that reapplies the
mode, and the writer that skips storing what the generator implies.
generatorIsFlat() is now the one closed set they share, and
builtinFilter() sets flat from it rather than inside a branch so the set
cannot drift from the labels.
Setting only the branch would have looked correct. Its save/load pair
survives by accident, because the writer's skip knew only "sent" and so
would have stored the key for drafts. The gap is the reader's fallback,
for a file carrying no flat key at all: an older build, a migration or a
hand edit comes back threaded against a flat button, and the next save
persists the disagreement.
theDraftsFilterIsThreadedNotFlat is inverted rather than deleted, keeping
its history, and now also pins Trash as threaded. The round trip is
covered by extending aGeneratedEntryWritesNoRedundantKeys, which already
asserted that property for Sent. Mutation-checked: reverting
generatorIsFlat() to "sent" alone fails both.
Suite 37 of 38; undoMovesTheMessageBack is item 136, pre-existing and on
an unrelated path.
Closes item 159.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UUQS6n3cmsFrsjCNmwNtf8
|
|
|
|
Autosave writes the draft to the Maildir drafts folder and stops, while
the Drafts view is a notmuch path: query, so a freshly saved draft was
invisible until notmuch new ran. saveDraftNow() now emits draftSaved, and
MainWindow connects it to a new NotmuchWorker::indexDraftFile() that
indexes the one file the way moveMessages() does, with the previous
revision removed so a rewrite leaves no ghost.
The send path unlinks a draft that was indexed while being composed, so
draftRemoved -> removeIndexedFile() drops its entry too.
Measured: notmuch_database_index_file assigns NO tags (unlike notmuch
new, which adds draft inbox unread), so no tag-stripping is needed and the
draft cannot leak into a tag:inbox view.
Item 158.
|
|
|
