jeremy-compostella / org-msg

OrgMsg is a GNU/Emacs global minor mode mixing up Org mode and Message mode to compose and reply to emails in a Outlook HTML friendly style.
GNU General Public License v3.0
276 stars 57 forks source link

Gnus HTML export contains buttonized attachments #119

Closed morganwillcock closed 3 years ago

morganwillcock commented 3 years ago

Hello!

I've noticed that the Gnus based HTML export of message content is including the additional attachment buttons which may exist in the Gnus article buffer. These are optionally added underneath the real message headers based on the value of gnus-mime-display-attachment-buttons-in-header. The default is t so org-msg content for previous messages will include what looks like an additional header. It will look similar to this:

Attachment: [2. text/plain]...

With more attachments it becomes more noticeable and so potentially more a problem.

The same problem doesn't occur when viewing articles as HTML directly from Gnus and I've realised it is because Gnus' own export process relies on an additional call to gnus-summary-show-article within a scope where gnus-mime-display-attachment-buttons-in-header is set to nil, which removes the buttons. In org-msg that additional function call has been disabled: https://github.com/jeremy-compostella/org-msg/blob/4c92c627b6cfb234fd257b714a5dbfc72d7af8d2/org-msg.el#L352

I imagine that re-enabling the additional function call is likely going to reintroduce a problem that was fixed in https://github.com/jeremy-compostella/org-msg/commit/0a4154fa64915f3cecd9dbe0bb3de5e40ed4fa25 so I've probably reached the point where I should ask for a recommendation on how I might try to fix it.

In the mean time it is possible to work-around the issue by toggling the buttons off before replying with gnus-mime-buttonize-attachments-in-header (W M h).

Thanks, Morgan

jeremy-compostella commented 3 years ago

I came up with a post-processing solution. Let me know what think of it.

morganwillcock commented 3 years ago

Thank you for making these changes. I had to add a missing ) and edit the matched value from "attachments" to "attachment" so that it worked in all cases by default. The "s" is only present in the header when it buttonizes multiple attachments.

I guess I can say that from a user perspective the matching isn't entirely straight-forward because of the way that the pattern is used internally. To ensure I deleted the correct header I tried this:

(setq org-msg-undesirable-headers '("^attachments?$"))

...but that doesn't match because of a leading newline on the element text and the additional string formatting which prepends an additional pattern, so to successfully be more specific I needed:

(setq org-msg-undesirable-headers '("\nattachments?$"))

I think it would be more straight-forward in use to allow the pattern that is specified in org-msg-undesirable-headers to anchor at both ends and to match after the leading whitespace on the element text has been trimmed. The use case would be that the user may want to specify that headers shouldn't be deleted based on a substring match.

But right now it does fix the issue in every case that I've tried, so that is much appreciated.

jeremy-compostella commented 3 years ago

I have changed the customization variable to be a list of regexp. It should be a little bit more flexible.

morganwillcock commented 3 years ago

Thank you. That seems to work with no issues.

For documentation purposes, I would imagine that anyone using Gnus would probably want to use:

(setq org-msg-undesirable-headers '("^attachments?$"))
jeremy-compostella commented 3 years ago

Yes this is the default value. I added a bit of documentation in README.org and pushed to master.