Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How does mutt generate the reply message body? #3488

Open
szkosma opened this issue Jul 27, 2022 · 4 comments
Open

How does mutt generate the reply message body? #3488

szkosma opened this issue Jul 27, 2022 · 4 comments
Labels

Comments

@szkosma
Copy link

szkosma commented Jul 27, 2022

Apologies if this has been covered, but I haven't been able to find an answer/solution to what I'm trying to achieve in the documentation or elsewhere in theg github issues.

I want to run a separate command on the original message body when viewing in the pager, and different command on the same message body when replying, to format the quoted body in the editor. This is because I'm converting some attachment types to text to preview in the pager, but I don't want these automatically included in the quoted message body when replying.

The only promising thing I could find about this is setting edit=<command> and compose=<command> in the mailcap entry for plain/text (in this case), but it seems to have no effect -- editing or composing a message always uses the editor as set in the neomutt configuration.

What am I missing?

@szkosma szkosma added the type:question Question label Jul 27, 2022
@gahr
Copy link
Member

gahr commented Jul 29, 2022

The pager setting controls the command to be use to page (view) the message. It defaults to builtin, which means use the built-in pager in NeoMutt. Not sure if that helps / if I got the question right.

@szkosma
Copy link
Author

szkosma commented Jul 29, 2022

That part I understand. I probably wasn't clear enough in my question, but what I'm asking is in two parts:

  1. Does NeoMutt take the body of the message as displayed in the built-in pager (using mailcap rules) and then process that to generate new quote levels before sending it to the editor when replying? Or does it regenerate the body of the message using the same mailcap rules before sending to the editor?

  2. Is there any way/setting to intervene to modify the message body as displayed in the pager when replying, so that the quoted message body which is sent to the editor is processed in some way (stripping certain words, for instance?)

The only way that occured to me feels very hacky and might not work depending on the answers to the above, but I thought that a send-hook that points to a different mailcap file with text/plain entry that processes the body could potentially work, but only I suppose if the reply body is generated again using the mailcap view command, rather than using what is already being displayed when reading the message in the built-in pager.

Would this work? Is there another way?

@gahr
Copy link
Member

gahr commented Aug 2, 2022

Oh, I got the question now. Perhaps we could look into using the compose field of mailcap when looking up a mailcap entry to use for reply. Currently, we only use it for the new-mime function to add new attachments when composing an email. That would be a breaking change, though..

Probably, setting mailcap on send-hook is how I'd work around it.

@nickwynja
Copy link

Perhaps we could look into using the compose field of mailcap when looking up a mailcap entry to use for reply.

I'd find this useful! I find myself often wanting to reply to HTML emails for work and would like to retain the original HTML in the reply body. In this case, I'd probably change my reply format to be more like Outlook's where there's a horizontal rule and then the header information for attribution, the original message HTML (without > quote prefix / <blockquote>).

I've tried a send-hook workaround but am not getting very far.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants