editnew: Use raw body text instead of rendered version

[guludo]

Rendering mail content via mailcap makes sense when viewing email, but not when reusing the email for composing a new message, as it is desirable to rather edit the "original" content and, if mailcap rendering produces ANSI CSI escapes, the user would be left with a bunch of garbarge characters.

Make sure that the editnew command do not render the body when creating the envelope.

[pazz]

Without having reviewed the code: IS this what we actually want here? I ask because IIRW, many mail clients sent out html mails with the plaintext alternative empty or not complete. So by default I would (personally) be able to respond to the rendered variant. With the current master version, you can respond to the plaintext alternative by first displaying the plaintext version in thread mode (togglemimepart) and then replying... thoughts? Quoting Gustavo José de Sousa (2024-02-19 18:06:30)

…

Rendering mail content via mailcap makes sense when viewing email, but not when reusing the email for composing a new message, as it is desirable to rather edit the "original" content and, if mailcap rendering produces ANSI CSI escapes, the user would be left with a bunch of garbarge characters. Make sure that the editnew command do not render the body when creating the envelope. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ You can view, comment on, or merge this pull request online at: #1648 Commit Summary • fd4b284 editnew: Use raw body text instead of rendered version File Changes (3 files) • M alot/commands/thread.py (2) • M alot/db/message.py (4) • M alot/db/utils.py (22) Patch Links: • https://github.com/pazz/alot/pull/1648.patch • https://github.com/pazz/alot/pull/1648.diff — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.*Message ID: ***@***.***>

[guludo]

On Tue, Feb 20, 2024 at 8:30 AM Patrick Totzke ***@***.***> wrote: Without having reviewed the code: IS this what we actually want here? I ask because IIRW, many mail clients sent out html mails with the plaintext alternative empty or not complete.

Maybe I missed thinking about other workflows. I have been using editnew exclusively to edit saved drafts, which are saved with text/plain content. The issue for me is that, by rendering it with mailcap, I endup with an email on the editor with a lot of ANSI CSI escape sequences.

So by default I would (personally) be able to respond to the rendered variant.

Hm. I find it surprising that editnew would be used to respond to email.

With the current master version, you can respond to the plaintext alternative by first displaying the plaintext version in thread mode (togglemimepart) and then replying... thoughts?

Assuming that editnew would also be used for email not originated from alot, yeah, maybe we would need to allow the user to choose between rendered and raw plain/text. Should we add an option to editnew?

…

-- Gustavo Sousa

Quoting Gustavo José de Sousa (2024-02-19 18:06:30) > Rendering mail content via mailcap makes sense when viewing email, but not when > reusing the email for composing a new message, as it is desirable to rather > edit the "original" content and, if mailcap rendering produces ANSI CSI > escapes, the user would be left with a bunch of garbarge characters. > > Make sure that the editnew command do not render the body when creating the > envelope. > > ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ > > You can view, comment on, or merge this pull request online at: > > #1648 > > Commit Summary > > • fd4b284 editnew: Use raw body text instead of rendered version > > File Changes > > (3 files) > > • M alot/commands/thread.py (2) > • M alot/db/message.py (4) > • M alot/db/utils.py (22) > > Patch Links: > > • https://github.com/pazz/alot/pull/1648.patch > • https://github.com/pazz/alot/pull/1648.diff > > — > Reply to this email directly, view it on GitHub, or unsubscribe. > You are receiving this because you are subscribed to this thread.*Message ID: > ***@***.***> > — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.Message ID: ***@***.***>

[pazz]

I think adding an option to èditnew`and perhaps a config switch for the default value of that option would make sense here, yes.

[pazz]

I'm going over old/stale commits towards making a release soonish.
Would you like to repackage this with the extra option and include in a release?
I think I now tend to agree with you that this is a good idea if editnew is used for drafts.