Hacker News Reader

I wish we had something like Markdown for email--to me that would be the sweet spot between the mess HTML email has become, and plain text which sometimes does lack in its ability to communicate information.

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.

I can't believe I never thought of this! Brilliant idea. Now just to solve the viewing problem...

The reverse should work for simple HTML.

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.

Using lynx (or elinks, in my case) to view HTML email in mutt is the historical solution. I think the desire here is for a reversible transformation. E.g. I can receive an HTML email, view it as Markdown, reply using Markdown, and then send an HTML email in reply.

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.

We're almost at that stage with HTML already.

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.

Well you can use pandoc too or w3m.

For some HTML mails, it is sufficient to use a mailcap file in combination with lynx or w3m:

  # ~/.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

If you want the full HTML experience, you can use this script [1], which uses python (there also is an older bash version) to convert the mail into standalone html to be viewed inside a browser.

  # ~/.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"

1: https://github.com/akkana/scripts/blob/master/viewhtmlmail

How about using Pandoc[0] as part of your wrapping pipeline? It supports the full round trip between markdown, HTML, and back. Seems like this would be a perfect use case for it.

[0] http://pandoc.org

This is insanely brilliant. I am now happy to use Mutt again.

Yeah, I came here to suggest pandoc too.

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.

If you folks have already done the legwork on this, could you please publish your setup?

Yes please! This sounds intriguing. I send plain text only from mutt but including HTML from Markdown via Pandoc would be very cool.

Here is what I use.

  # 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"

Thanks!

I think you are solving the wrong problem.

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.

Many people use Android Mail which cannot send mail in text/plain if i understand correctly https://code.google.com/p/android/issues/detail?id=8712

Is this kind of condescending, elitist remark destroying one of the few last redeeming qualities of email? That everyone can talk to everyone else outside of walled gardens?

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.

That's nice, grandpa. I'm probably physically older than you, but I mostly commonly see your attitude when I'm sipping beer with old vets down at the Elks lodge.

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.

With all due respect: your approach here is to tell a billion people to jump over the Grand Canyon or kiss your ass and die.

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 see every day people being owned by phishing and malware and their privacy compromised because they are accepting HTMaiL.

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.

I get the frustration. But I think that war's been lost.

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.

Go ahead and write Markdown. Every one of your recipients will understand, as Markdown is essentially taken from how people write plain text email (> for block quotes, * for bulleted lists, _ for emphasis etc.).

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'm not a mutt user, but I believe in the power of text. Look at your comment. It's a lot of text, and zero formatting. But still it's powerful at achieving what you want to achieve. I really don't see why you need that kind of html stuff or markdown, or inline attachments, etc.

yeah to hell with those latex documents and word processors, behold the .txt file!

But latex and word are usually for printing a document. For something that will later be printed, you would want some sort of control over the actual look as the appearance is a large part of what is being communicated. Printing is also much more expensive than sending electrons so you would expect a much more developed medium for this.

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.

I've switched to using Emacs (with mu4e + offlineimap). Composing pretty emails using Orgmode is great. It's even possible to render code snippets with code highlighting taken from your current theme. Attachments handling is pretty great as well. My only problem is rendering of HTML emails is not good. It tries its best, but most of the time it doesn't work (about 50/50 from my experience).

Have you tried an Emacs with eww which relies on libxml2 for HTML parsing?

Have you tried isync (mbsync), instead of offlineimap?

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

Yes, offlineimap crashes every few hours. Not a big deal for me (I don't get a lot of emails), but it is annoying. I'll give mbsync a shot.

(mu4e author here)

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.

Have been thinking about markdown email support as well. That would solve many of our problems!

If you are on a Mac, try https://freron.com/. I moved to it from Mutt. It uses Markdown to write emails, has fantastic search capabilities, etc.

Im using markdown for writing email, and then on "send-message" I have macro that converts to html (pandoc), and sends an e-mail.

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

I use Markdown Here for this - - compose in Markdown, click a button, get nice html-formatted email.

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