This advice admittedly makes sense for conversations within a certain programming culture, but often doesn't make sense in other contexts where the use of email

This advice admittedly makes sense for conversations within a certain programming culture, but often doesn't make sense in other contexts where the use of email, and what people need from it, might be different. It's unfortunate that the proponents of this type of plaintext email try to push it so universally and uncompromisingly: it seems dismissive of other fields. It's actually one reason why I decided against using sourcehut for projects: with a project on sourcehut there is no way to avoid giving others the impression that you wholly support this view, and I don't. In my experience, for example, plaintext email works poorly for many scientific discussions. Simple figures/plots are often quite helpful, and putting them as attachments that don't show up inline is annoying: it's enormously annoying when getting unformatted, figures-at-the-end Word documents for peer review that some people use rather than formatted PDFs, and it's annoying with email. Math is problematic: there are people who are fluent enough reading and writing LaTeX math source in emails, but as it becomes more complicated, it becomes both a burden to read for the LaTeX-fluent, and undecipherable to those not familiar: saying, eg, $a_i = 2 * i^2+5$ might be comprehensible enough to someone who doesn't otherwise use LaTeX, but what about when you start having \frac, \sim, \mathrm, \align, \gather, etc? Years ago, when I used to send exclusively plaintext emails, I found myself frequently getting to a point writing an email where I'd decide it would be better to send it as a PDF with something like "see attached", and that's annoying in a completely different way! What's particularly unfortunate about the insistence on an uncompromising pure-plaintext, hard-line-break position is that there could be incremental, backwards-compatible improvements that would represent reasonable compromises rather than simply surrendering to the mess of full-HTML email and the horrors of many bulk HTML emails many of us see. Having a standard way of sending Markdown emails would open up the possibility, for example, of having reasonable, simple formatting, inline images, and with support, math, while not diverging from the text-centric format. It would also fix the flow vs verbatim problem. MIME multipart already makes it possible to send text/markdown parts, and it could be made backwards-compatible with other clients using multipart/alternative with text/plain and text/html renderings. I've actually done this from time to time, with some clients, but it is often frustrating and complex to set up as a custom process, and, of course, no one else's client is actually reading the text/markdown parts of my email. Yes, Markdown has its inconsistencies, but they'd surely be better than the mess of HTML support inconsistencies, while still being better than plain text. In fact, when writing plain text emails back and forth, I find many people often end up naturally writing with at least some Markdown-like formatting anyway. I can also easily write messages in Element, or many other non-email places, and have basic formatting and often math with Markdown. MIME wouldn't even necessarily require that a single markup be chosen to support. Yet I feel like the plaintext purists won't recognize that there are compromises that would work for a more diverse group of people, and so instead end up insisting everyone should follow practices that are well suited only for what they do. And so their view ends up being increasingly marginalized, when their resistance to the real mess of HTML support (both in display and composition) in email clients is quite reasonable. That's a problem that I think many people find frustrating, and an understanding approach to solving it would I think find far more support.