mu4e-compose-signature interference

[hubert-mns]

I am probably missing something obvious but if I have mu4e-compose-signature set, when I compose a new mail, it becomes part of the quoted and read-only section. Furthermore, if I have org-msg-text-plain-alternative to tthen this signature will figure inline at the top of the email for the recipient.

So the solution for now is to have mu4e-compose-signature to nil and not send plain text alternative.

Is it expected?

[jeremy-compostella]

Hi,

Yes, unfortunately, org-msg cannot be compatible with features like this and this is why it provides its own version of this feature.

Why don't you configure the org-msg-signature instead of mu4e-compose-signature ? Below is my configuration:

(setq org-msg-signature "

  Regards,

  ,#+begin_signature
  -- *Jeremy* \\\\
  /One Emacs to rule them all/
  ,#+end_signature")

Regards, Jeremy

[hubert-mns]

Thanks @jeremy-compostella. That's fair and that's what I have done now.

I haven't fully integrated org-msg in my flow. I tend to deactivate it for forwarding or when I want to be sure I send the email in plain text. In these situations, I therefore get no preset signature which I can live with.

While I am here, I read in the README that org-msg will detect when plain text is ok and won't activate itself in compose mode if so. Can you tell me more about the trigger here? I don't think that's what I am seeing.

Otherwise we can close this one. Thanks again!

[jeremy-compostella]

Hi,

If you reply to an email which is plain text, org-msg will detect and will not use any of the "html" feature, will not use the org-msg signature, will not modify the buffer, ...

Since you use mu4e the detection is going to done by the following function:

(defun org-msg-article-htmlp-mu4e ()
  "Return t if the current mu4e article is HTML article."
  (when (mu4e-message-field mu4e-compose-parent-message :body-html) t))

Regards, Jeremy