[RFE] Add original message's attached patches inline when composing a reply

[sergiodj]

Is your feature request related to a problem? Please describe.

I receive a lot of emails with patches as attachments, and I would like mu4e to add those patches inline in the reply message when composing it. Gnus does this by default, but I could not find a way to configure mu4e to do the same. I'm tempted to define an advice around mu4e--compose-cite, but I'd like to see this upstreamed.

Describe the solution you'd like

When I hit R or W to reply to a message, and if this message contains patches as attachments, then I would like to see mu4e add the contents of those patches inline in the reply message.

Describe alternatives you've considered

As mentioned above, I'm considering adding an advice around mu4e--compose-cite to do that.

Thanks!

[djcb]

E-mail clients typically include attachment only when forwarding messages, not with replies, and I think that's a reasonable default behavior. Does Gnus do that differently?

Anyway, mu4e use the Gnus machinery for replying, so it might be possible to tweak that; see message.el.

I wouldn't recommend using the advice-mechanism, esp. not on on an internal function; you can customize message-cite-function though.

[sergiodj]

Thanks for the quick reply.

E-mail clients typically include attachment only when forwarding messages, not with replies, and I think that's a reasonable default behavior. Does Gnus do that differently?

Maybe I wasn't very clear; let me try explaining again.

Suppose you get an email that contains a patch as an attachment, not inline. You read the message, hit RET on the patch to see its contents, and then decide to compose a reply. When you do so, you would like to make comments on the patch you've just received. For that reason, you expect your email client to add the contents of the patch inline in your reply (i.e., not as an attachment).

Gnus does this, but mu4e doesn't. IIRC this is the default behaviour on Gnus; I don't have anything in my ~/.gnus that seems to enable/disable this feature.

Anyway, mu4e use the Gnus machinery for replying, so it might be possible to tweak that; see message.el.

Unfortunately I don't think it is possible to tweak tweak it :-/. I believe this is just a difference in the way Gnus prepares the reply message vs. how mu4e does it.

I wouldn't recommend using the advice-mechanism, esp. not on on an internal function; you can customize message-cite-function though.

Right, I thought about using that, too. Thanks for the pointers.

[djcb]

So gnus takes a message with an attachment and inlines that attachment in the reply? Does it it only do that with patches? Or all text-based attachments? Some other rule?

[sergiodj]

So gnus takes a message with an attachment and inlines that attachment in the reply?

Yes. As long as the attachment has been expanded in the original article, it inlines it in the reply.

Does it it only do that with patches? Or all text-based attachments? Some other rule?

It does that for all text-based attachments. It's pretty convenient not only when someone sends you patches, but also if they send you a draft in text/plain attached to their message and you want to review it inline.

[sergiodj]

I had some time to hack on this and here's the solution I came up with:

  (defun sdj/mu4e-message-cite-attachments ()
    (when-let* ((article-buffer (get-buffer "*mu4e-article*"))
		(mime-parts (with-current-buffer article-buffer
			      (mu4e-view-mime-parts))))
      (dolist (mime-part mime-parts)
	(let ((mime-type (plist-get mime-part :mime-type)))
	  (when (and (plist-get mime-part :attachment-like)
		     (string= (plist-get mime-part :disposition) "attachment")
		     (string-prefix-p "text/" mime-type))
	    (when-let ((mime-handle (plist-get mime-part :handle))
		       (mime-filename (plist-get mime-part :filename)))
	      (save-excursion
		(goto-char (point-max))
		(while (not (looking-at-p
			     (rx-to-string
			      `(: line-start "[" (+ digit) ". " ,mime-type "; " ,mime-filename "]") t)))
		  (forward-line -1))
		(forward-line)
		(insert "\n")
		(mm-display-inline mime-handle)
		(set-mark (point-max)))))))))

(setq message-indent-citation-function '(sdj/mu4e-message-cite-attachments message-indent-citation))

It's not the most elegant but it works for my use case. While implementing it, I found a few pain points:

• It doesn't seem to be possible to reliably get the mu4e-article buffer that's being replied to. I had to resort to calling (get-buffer "*mu4e-article*"), but it feels fragile.
• According to

  mu/mu4e/mu4e-message.el

  Lines 73 to 75 in 7dc8216

  	- Messages in the Headers view come from the database and do not have
  	:attachments or :body fields. Message in the Message view use the
  	actual message file, and do include these fields."

  it should be possible to access the :attachments field from a message in Message view, but I wasn't able to. I had to rely on (mu4e-view-mime-parts) instead.
• It took quite some time to figure out that I had to call mm-display-inline to properly show the attachment. I was using mm-display-part before, but it doesn't seem to work for every MIME type. This isn't an issue with mu4e, but I thought I'd raise it here anyway.

[djcb]

Oh, nice you got something working!

Yes, mu4e re-uses some of the gnus machinery which isn't really designed for use outside gnus; and extending mu4e in this way takes it to yet another level. So that's sadly all a bit fragile. Note that the gnus metadata is available as available as text properties, so at least the regex matching could be avoided.

[sergiodj]

Thanks for the tip. I believe the text properties are stripped in the compose buffer; I can't find any Gnus metadata there :-(.

[djcb]

Yes, sorry I meant that in the view buffer / article buffer; i.e, setting up some off-screen buffer. mu4e-view does this, though admittedly it's fairly ugly, trying to make gnus work in that context.