[mu4e bug] The "current email" in headers view is out-of-sync with visually highlighted one

[bramadams]

Describe the bug

When back in message view after sending out a reply or a forwarded email, the currently highlighted email in headers view often is no longer the "real" current email on which actions like mu4e-view-headers-next or mu4e-view-mark-for-read will act. Instead, the latter actions jump to/mark a different email than expected, after which the highlight face is applied to the updated selected email.

The expected behaviour would have been for the visually highlighted email in headers view to remain the real current email for actions to apply on. The workaround further below fixes this.

How to Reproduce

I encounter the issue all the time, but it actually is quite hard to reproduce deterministically. Eventually, I believe it is triggered by a long-running action like composing an email during which the underlying email archive is re-indexed and the visually highlighted email is no longer accessible (for example, was marked as read).

In other words, the issue most likely surfaces as follows:

• mark a sequence of emails as read in headers view, except for an email in the middle of this sequence
• select the latter email in headers view, opening it in message view
• reply to this email, spend some minutes here
• eventually submit the email
• invoke (for instance) mu4e-view-headers-next
• notice that the highlighted email jumps abruptly

Environment

Emacs 30.2 on MacOS with mu4e 1.12.5 (but the issue has been there for much longer).

Workaround

After a lot of trial and error, I recently found a workaround that resolved the issue for me, but which led me to believe a more fundamental fix in the code base is needed:

  ;; Fix: Ensure headers position matches view message after compose
  ;; This prevents the bug where header actions operate on the wrong email
  ;; after replying/forwarding, caused by the fallback in mu4e--view-in-headers-context
  (defun my-mu4e-sync-headers-with-view ()
    "Synchronize headers cursor position with the current view message.
This ensures the visually highlighted message matches the internal state,
preventing actions from operating on the wrong email."
    (when-let* ((view-buf (mu4e-get-view-buffer))
                (msg (with-current-buffer view-buf
                       (and (derived-mode-p 'mu4e-view-mode)
                            (bound-and-true-p mu4e--view-message))))
                (docid (plist-get msg :docid))
                (headers-buf (mu4e-get-headers-buffer)))
      (with-current-buffer headers-buf
        (when (buffer-live-p headers-buf)
          (mu4e~headers-goto-docid docid)))))

  ;; Run after compose finishes to ensure headers/view are in sync
  (add-hook 'mu4e-compose-post-hook #'my-mu4e-sync-headers-with-view)

Checklist

• you are running either an 1.10.x/1.12.x release or master (otherwise please upgrade)
• you can reproduce the problem without 3rd party extensions (including Doom/Evil, various extensions etc.)
• you found a workaround (which needs a more definitive fix in the code base)
• you have read all of the above

[djcb]

I've pushed a candidate fix for this... can you try? Thanks!

[bramadams]

Great, thanks, will check it out and report back.

[bramadams]

Hi, the fix seems to be working well. Still testing, but did not encounter the issue thus far.

[djcb]

Great! Thank you for testing. I'll close this now then, hopefully forever :)