From 6326030b7179580b934ba852b0fd98577bfb464a Mon Sep 17 00:00:00 2001 From: "Danilo M." Date: Sun, 6 Sep 2026 16:55:16 +0200 Subject: fix: index the sent copy so it appears in the Sent view at once ComposeWindow filed the sent copy into the account's sent folder and discarded the path DraftStore::write() returned, using the result only to test for failure. Nothing announced the file, so notmuch never learned it existed, and the Sent view is a path query over the index rather than a listing of the folder: the message was on disk and invisible until the next notmuch new, which here is a cron tick up to ten minutes away. Measured immediately after a send: 65 files in the account's Sent folder, 64 messages indexed for the same path. This is item 158's defect one path over. That item established the rule for drafts, and MainWindow wires both halves of it, so the send path was already telling the worker to DROP the draft's entry while never telling it to add the sent copy's. The missing half is the one the user sees. A sentCopyFiled signal, emitted only where the write succeeded, connected to the worker's existing indexDraftFile. That slot is generic despite its name: it calls notmuch_database_index_file, applies nothing draft-specific, and its previousPath already defaults to empty, which is right for a copy that replaces nothing. The connection is a lambda whose context object is m_worker, and that is load-bearing. indexDraftFile takes two arguments where the signal carries one, so a direct slot connection does not compile; the context object is what queues the call onto the worker's thread and keeps notmuch off the GUI thread. Simplifying it to a plain call reads as tidier and would cross that boundary, so the comment says so. The test asserts on the signal, on the file existing, and on it being inside the Sent folder. Indexing itself is already covered against a real database in test_notmuchworker; what was unproven was that anything ever called it for a sent copy. Announcing a path that was never written is the ghost entry removeIndexedFile exists to undo, which is why the existence check is there. Indexing is not repainting: a Sent view already on screen does not gain the row from this, and whether it should refresh after a send is left as a separate question. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01Jq9gXquUo9W4KXDagJXMmn --- src/composewindow.cpp | 8 ++++++++ 1 file changed, 8 insertions(+) (limited to 'src/composewindow.cpp') diff --git a/src/composewindow.cpp b/src/composewindow.cpp index 218edef..59228ba 100644 --- a/src/composewindow.cpp +++ b/src/composewindow.cpp @@ -1616,6 +1616,14 @@ void ComposeWindow::send() if (!filed.ok()) { sentCopyFailed = true; sentCopyError = filed.error; + } else { + // Item 192. The Sent view queries the INDEX, so a file + // notmuch has not seen is invisible there until the next + // sync. The path was previously discarded, which is why a + // message just sent did not appear: measured as 65 files + // against 64 indexed. Only on the success branch, since + // indexing a path that was never written leaves a ghost. + emit sentCopyFiled(filed.path); } } -- cgit v1.2.3