feat(compose): offer Edit on a draft in the message pane's bar

Item 157, the half item 153 did not close. A draft was editable by
double-click and by a Message-menu entry, neither of which is where the
user looks while reading one. populateMessageBar() swaps the reply pair
for edit_draft on a displayed draft.

Three things came out of hand-testing it, each invisible to the tests
written before them.

The bar keyed on currentIndex(), which a query leaves valid on a row of
the discarded result, so it kept the draft button after switching to the
inbox and the reply pair after switching to drafts. This is item 150's
trap one level up. It answers from m_currentMessageId/m_currentThreadId
now, which every blanking route clears, refilled from
showPlaceholderPane(), the one site all five of those routes share.

That exposed a defect predating the bar: updateComposeActions() ran only
from the two selection handlers, so Reply and Forward stayed enabled over
a blank pane. Invisible while they sat on the main toolbar among
always-on actions.

The bar is hidden over an empty pane, so it comes and goes with the
subject and the details button rather than hovering over the logo. That
in turn broke the showing half: setBarActions() runs before showThread()
fills m_items, so the first message opened after a blanking left the bar
hidden and the second showed it from stale items, one selection behind
for the life of the view. updateHeader() shows it, beside the details
button it rides with.

The test missed the last one by asserting before the render landed,
measuring the placeholder; it waits on showingPlaceholder() now.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KEcn3u19xPqv6ggD15PG4c

1 files changed, 21 insertions, 1 deletions

diff --git a/src/messageview.cpp b/src/messageview.cpp
index 4c2a9d0..86e40eb 100644
--- a/src/messageview.cpp
+++ b/src/messageview.cpp
@@ -617,7 +617,18 @@ void MessageView::setBarActions(const QList<QAction *> &messageActions,
         }
     }
 
-    m_messageBar->setVisible(!m_messageBar->actions().isEmpty());
+    // Hidden over an empty pane whatever it holds, so it comes and goes with
+    // the subject and the details button rather than hovering over the logo.
+    // The user's call, and the reason is consistency with those two: a bar
+    // that persists was the only piece of header furniture that did.
+    //
+    // This guard covers the HIDING only. MainWindow refills the bar from
+    // showPlaceholderPane(), which every route that blanks the pane passes
+    // through, so the refill re-reads m_items and this line answers. Nothing
+    // refills it when a message ARRIVES, so updateHeader() shows it there;
+    // see the note beside the details button, which it rides with.
+    m_messageBar->setVisible(!m_messageBar->actions().isEmpty()
+                             && !m_items.isEmpty());
 }
 
 void MessageView::clear()
@@ -754,6 +765,14 @@ void MessageView::updateHeader()
     // scratch a few lines down.
     m_headerOffers.clear();
 
+    // The bar rides with the details button, but only the SHOWING half belongs
+    // here. Hiding is covered by setBarActions(), since MainWindow refills the
+    // bar on every route that blanks the pane, and a hide() in the empty
+    // branch below was measured to change nothing. Nothing refills the bar
+    // when a message ARRIVES, though, so without the show() below it stayed
+    // hidden for the first message opened after any blanking and appeared on
+    // the second, when m_items still held the first: one selection behind for
+    // as long as the view lasted.
     if (m_items.isEmpty()) {
         m_headerLabel->clear();
         m_detailsButton->hide();
@@ -761,6 +780,7 @@ void MessageView::updateHeader()
     }
 
     m_detailsButton->show();
+    m_messageBar->setVisible(!m_messageBar->actions().isEmpty());
 
     // The thread's subject comes from its first message; later replies carry
     // Re: prefixes that add nothing.