I don't use mutt but IIRC a basic feature of both mutt and similar (pine + variants, etc.) is allowing you to define your own external editor. Therefore, there's nothing to stop you adding a wrapping pipeline to that so that, for example, first you edit normally in your preferred editor, and second an established piece of code or basic series of regex replaces your markdown with whatever you actually want. Optionally, the reverse runs before editing. This should not take longer than a few hours on the outside to get running comfortably.

The problem isn't HTML, it is its users. People who can't quote properly, people who end every single sentence with an emoji, etc. In a nutshell, people who have never experienced Usenet never learned how to communicate properly with a keyboard.

The fix for this is to configure your email client to auto-answer a rejection message when it receives anything other than plain text. You can always blame your antivirus for that.

Help people with disabling HTML email. With a little bit of luck, they won't remember how to enable it again. And hopefully, since they won't be distracted any more with fancy formatting, animated smiley and which GIF-meme-to-use-for-this, hopefully they'll focus on words and reinvent ascii art.

Don't get me wrong, I'm a big fan of plaintext email (and use mutt at work) but it's not practical to expect the world to bend to your own narrow choices in technology so harshly. The attitude displayed here is, quite frankly, disgusting.

Just because we invented and pioneered the early 'net doesn't mean we own it. Things change and usage patterns evolve as people join and leave the medium. Email today is a medium for HTML and emojis for almost everyone using it, except for the curmudgeons. We don't get to define "communicates properly".

Don't be a curmudgeon. This isn't "our" system anymore, if it ever was at all.

Within a given organisation (if you're exceptionally lucky), or on some mailing lists, you might be able to enforce discipline. At large, though, this mostly doesn't scale.

I think it's unfortunate -- there's a very strong degree to which standards of message formatting are useful and helpful. And, in counterpoint to much of the disagreement to your point, it's not as if a bunch of Unix geeks in the 1970s and 1980s started the concept -- go through any "how to succeed in business without really trying" manual from the 1920s through 1970s, and you'll find strongly specified guides on how you are to type and format your business correspondence (using your monospace Royal, or later, IBM Selectric, typewriter). And deviations from those standards were not appreciated.

But until and unless some Hand of God comes down and enforces discipline again, we're in our current State of Babel.

On the other hand, client quirks are so common now that configuring you email stream to:

1. Render all incoming messages as flat, 72-character, ASCII

2. Outputing messages with same, '> ' quoting, etc., etc., is pretty much perfectly justifiable.

"Oh, my email doesn't handle attachments or binaries, I'm sorry."

If you are in a position to ensure people talk to you on your terms, so much the better. I can approach that, but there are sacrifices to be made.

My approach is to go as far as I must to meet them halfway because I know I wasn't born perfect either.

Engineers are brilliant in ways that are rare, valuable and admirable. But they don't tend to have a great level of empathy and trust me, it's something worth cultivating.

I've heard people complaining about email conversations that they can't understand any more because every one used together top-posting, bottom posting, coloured inline replies and no trimming.

I want this madness to end. If it isn't empathy, what is it?

It's no different than telling billion people to stop using Flash or kiss a specific part of my body and rest peacefully. Except perhaps that we are a few anonymous "disgusting elitist curmudgeons" instead of being huge internet companies.

[0] http://pandoc.org

You can easily script mutt to include a plaintext file and an html one generated by pandoc, so that people reading your emails can fall back to a plain text version of your mails in case they can't view html.

  # convert markdown to html via pandoc
  # https://unix.stackexchange.com/questions/108485/send-    email-written-in-markdown-using-mutt
  macro compose \e5 "F pandoc -s -f markdown -t html \ny^T^Utext/html; charset='utf-8'\n"

  # ~/.mutt/mailcap
  text/html; w3m -I %{charset} -T text/html; copiousoutput;

  # ~/.muttrc
  alternative_order text/plain text/enriched text/html  # save html for last
  auto_view text/html

  # ~/.muttrc
  macro index,pager M "<enter-command>unset resolve<enter><clear-flag>N<enter-command>set resolve<enter><pipe-message>viewhtmlmail\n" "View HTML in browser"

For complex HTML to plain text try https://www.google.com/search?q=lynx+convert+html+text .. most text browsers can do a reasonable job of it.

Unfortunately, I think foreign email clients would mangle the HTML just enough to stop this from working. You'd have to start implementing a tag soup type parser to coax incoming mail into something intelligible.

I'm thinking that a multi-pass parser:

1. Is this sane HTML5 markup? I'll eat that.

2. Is this a borked-but-manageable variant? Strip the cruft.

3. Is this Beyond All Hope? Just dump it as ASCII. It'll be blockquoted in reply.

HTML is no longer a peresistent, stable, or universal interchange format.

I've seen that some graphical clients seem to interpret these characters. It's common for block quotes to be colorized and foldable, for example. (But what do I know? I'm an old fart in email matters.)

I have never printed an email in my life. The appearance of the text is not essential to what is being communicated. Here a certain consistency is more important that variety - or rather the variety comes through the vocabulary and written expressions, not the font shape.

The same could be said for IM clients or IRC. Except for a few minor tweaks such as html links there is no real need for text formatting in these mediums, and very few clients even make the effort to do this.

Mu4e has a few different options for displaying rich-text messages. In recent emacsen, it defaults to a shr/eww based display; it's not perfect, but it reduces the set of problem cases.

For those, there are the view-in-browser action, and with (as of yet unreleased) emacs-25 you can use a webkit-based display embedded in emacs.

With those, I'm able to view just about any message; even the ones I get from airlines etc., which tend to be html-only.

Anyway - to get back to the top-level subject: congratulations to mutt, which is a great e-mail client, and a big influence on mu/mu4e.

I found offlineimap slow and crashy, and switched to isync.

I agree with you, html mails can be usefull and people like them more than plain text (specially marketing,sales, etc).

I believe I have sweet spot with mutt, lot of custom configs being very productive, but not ignoring html . Sidenote, I use xombrero to view html mails if they are complex (inline images etc) - it is very fast and always shows mails correctly

One annoyance is not being able to get back the original markdown. But a mutt workflow could easily deal with this.