Hacker News new | past | comments | ask | show | jobs | submit login
Markdown Here – Write email in Markdown (markdown-here.com)
349 points by duck on Nov 7, 2017 | hide | past | web | favorite | 182 comments



I absolutely love this extension and it's been a stable part of my workflow for the last 2 years or so.

For people who are asking what the use case for this is have clearly never tried sending chunks of code over email (especially a auto-word-wrapping HTML client like Gmail). Markdown Here allows me to create beautifully formatted code blocks which are readily shared with the rest of the team and beyond (Even non-Engg love reading well formatted blocks of markdown).

My workflow for a lot of mails sent out to other teams involves the following template:

----

Hey there! I ran into this error while running XYZ service. The error seems to be with a background sync script that is failing to update data. The call and params along with the response is shown below:

```

insert block of code here

```

Please let me know how to resolve this. We can get over a quick Hangouts call if necessary.

----

Select and "toggle markdown" using the extension. Send!

YMMV, but this extension has been a gamechanger for me! Thanks for an awesome extension! :)


> Thanks for an awesome extension!

You're welcome! (I won't reply to every positive comment, but...)

The impetus for me to create Markdown Here was mostly a) code blocks, b) nested bullet lists (which are fiddly and hotkey-heavy in a rich editor). (Brief origin story, fwiw: http://markdown-here.com/about.html )


Any chance of creating a Brave extension? https://brave.com/

I know probably not, but it's the only browser I use for gmail. It's so convenient keeping it open in the background, isolated from my main Chrome browsing workflow. Whenever I get an email I get a nice OSX popup. I know Chrome can do this too but I restart Chrome like five times a day.

Brave is pretty good, but doesn't get much love. Hopefully it'll catch on more.

Thanks for your work!


A few seconds of research suggests that it's worth investigating more (i.e., it seems like Chrome extensions might be supported without too much effort). https://github.com/adam-p/markdown-here/issues/465


Is their crypto currency ad replacement system in play? I recall that being one of their very early pitches.


Do they have tabs on the side?


Nah. Admittedly the tabbing kind of sucks. You can't even tear off tabs into windows.

Tabbing is an interesting thing... I've always been jealous of Firefox's tree-style tabs, which are impossible to implement on Chrome. But never quite jealous enough to give Firefox another shot. Yet.


Try Quantum, in beta until next week. Just trying it now and very impressed:

https://www.mozilla.org/en-US/firefox/channel/desktop/#beta


Beware. Tree style tabs has become quite slow on newer Firefox (nightly)


I was one of those people wondering why I would use this and I have sent code via Gmail without problems. Personally I generally prefer plain text email. But I could imagine trying this out. Nice to see some positive endorsements.


If I am not mistaken, this is plaintext email. Traditionally, email had bold, /italics/ and _underline_. Markdown just extends on this. The danger is, however, that people continue to create their own Markdown extensions and we end up with emails, that are full with those "control-codes", which makes them ugly for anyone, not having a transformer in their email-client (aka: those, who read the plaintext)


You're mistaken. This converts the markdown HTML and sends an HTML e-mail. There wouldn't be much point if the receiver required a plugin they're unlikely to have. http://markdown-here.com/features.html


Usually Mail clients send mails as multipart/alternative with both a text/html and text/plain.

It makes sense to keep the entered markdown as the text/plain part. But if this looks ugly, then the plain text view won't be as pleasant.

PS.: I hate all companies that think their newsletter only needs text/html, and put a "Please read me with an HTML-compatible mail client" as text/plain.


Most html mail I get just links to a jpg poster in crappy resolution.


How about replies to such emails?

The need to quote previous emails or reuse pieces of them often arises - it would be convenient if the original markdown source was available, but with HTML, is it convenient?


Wow. I thought this was just a little neat. When you pointed out writing code, it instantly clicked for me that this has real power to improve my process. I love markdown in Slack for sharing code. I will inline commands and snippets all the time. Now I can do it in emails easily. Huge win!


> I love markdown in Slack for sharing code. I will inline commands and snippets all the time. Now I can do it in emails easily. Huge win!

Once upon a time email was always pure text, and you'd have been free to use Markdown to your heart's desire.

I think that the Right Thing™ here would be for mail clients to support RFC 7763, which specifies the text/markdown content type.


I'm the author of Markdown Here. And surprised to open HN and see it on the first page! I can answer any questions (although it's really a straightforward tool -- it does what it says on the box).


Hey Adam, you should probably avoid marked.js.

It suffers from a number of security issues [1] and it's unmaintained (or at least the maintainer is AWOL and without him new releases can't be tagged).

Markdown-it is probably a good alternative. [2]

[1]https://github.com/chjj/marked/issues?utf8=%E2%9C%93&q=is%3A...

[2]https://github.com/markdown-it/markdown-it


I started the switch to markdown-it a while ago[1]. I just need to find some time to get back to it.

[1]: https://github.com/adam-p/markdown-here/tree/markdown-it


Why did you use marked instead of markdown-it or another CommonMark-compatible parser? Have you thought about switching to a library which supports more features?


Markdown Here predates both CommonMark and markdown-it by a couple of years. marked.js was the best choice when I created MDH. That being said, I have started work on switching to markdown-it (see comment above).


If possible, you should make an outlook add-in. I would pay for that.


As would I


Hi Adam! I installed Markdown Here from the Chrome Web Store, and I noticed it installed 2.12.0. However, it looks like you released 2.13.1 on GitHub. Should I be installing from GitHub?


2.13.1 and .2 are Mozilla-specific releases, to deal with the change from XUL to WebExtensions in Firefox, while still supporting Thunderbird (and Postbox) and old Firefox (and Palemoon). I'll cut a release soon-ish to fix a couple of bugs: https://github.com/adam-p/markdown-here/blob/master/src/comm...


How could one write 64px red bold underlined "DO NOT REBOOT THE WEBSERVER!!!!!!!!!!!!!!!" with this?


I can't tell if you're kidding, but... Markdown Here gives you control over the CSS used when rendering, so you can put those loud styles on, say, H1, and then just write:

# DO NOT ET CETERA

...And then render.


Is there a way to use just the markdown -> html so that it can be used for automated sending e.g. via mandrill/sparkpost?

It looks pretty!


that... just... that doesn't make sense. why would you use a plugin that converts markdown to html in browser windows to do automated sending. There have been command line tools to convert markdown to html since the beginning (literally, first implementation by gruber). Pandoc is probably the go-to one these days but yeah, that's just.... not the right tool for the job.


There's an issue asking for this: https://github.com/adam-p/markdown-here/issues/43

It's not super high priority, but someday...


Maybe the answer is to return to sending plaintext emails? HTML emails are an abomanation. Rather than extend them, just ditch them.


We have lost this battle, but keep fighting the good fight. We've also lost to top-posting and JavaScript.


Top posting only won in places where everyone uses Outlook. Mailing lists still use quoted style.


Gmail also had a big hand in the reduction of top posting, by hiding the quoted message by default (click the little '...' icon to see it).

This means that replies in-line, or below quoted text are instantly hidden and then you get complaints from the technically challenged who insist the email you sent was blank.

I tried to educate and fight back for a long time, but too many important things were lost to those who insist on writing right where the cursor appears instead of taking a moment to position it thoughtfully, and alas the rest is history.


Of course I meant "... in the growth of top posting...", I think most of you got the gist that I'm not a fan.

   100a I must express myself clearly when posting. <return><esc>


The fact that Gmail hides the quoted portion actually encourages people to use top posting more.

Which is a great thing.

I know, not a popular opinion here, but top posting saves a lot of time in catching up with long email chains.

If you don't agree, pick an old style mailing-list like a Linux kernel discussion, choose a discussion with 20+ emails in and read it from top to bottom. You'll quickly realize how exhausting inline quoting is.


Less exhausting than reading each of those 20+ emails separately. For any conversation of substance, you need the relevant context before you can understand the reply.

If context isn't required, then don't include it. Inline replies act as a forcing function, directing people to reply to the substance of what was said. That necessarily includes eliding irrelevant bits, which is often the most helpful aspect. Neither top posting nor bottom posting help emphasize substance.

In high quality forums inline posting is extremely useful for both reader and author. For the Outlook and Twitter set, it's a pointless debate.


Either you're part of an active email chain (e.g. happening over a period of a few hours), in which case you have the context. You don't need to read it over and over again, so the best place to put it is below the signature. Top posting wins here.

Or you're catching up on a discussion that happened in the past, reading each email one after the other. Again, the context is secondary, so the best place is to put it below the signature. Again, top posting wins.

For these rare emails where specific answers need to be positioned below some specific context, the writer of the email needs to have the discipline to put it there, and this can be achieved with top posting as well.

Inline quoting has really no good reason to exist in most email chains.


There are two relevant senses of context: what has already happened in the email thread and what a given person thinks he is responding to. Top posting is better for an outsider who is just reading through the thread while inline replies help the people in the thread understand where a given author is coming from.


That's pretty ridiculous. Inline quoting permits folks to trim the replied-to text to only the relevant portion. There's no need for each email to carry with it a complete record of the conversation up to the point that it was written.

If you don't agree, keep on reading.

hota_mazi writes:

> The fact that Gmail hides the quoted portion actually encourages people to use top posting more.

> Which is a great thing.

> I know, not a popular opinion here, but top posting saves a lot of time in catching up with long email chains.

> If you don't agree, pick an old style mailing-list like a Linux kernel discussion, choose a discussion with 20+ emails in and read it from top to bottom. You'll quickly realize how exhausting inline quoting is.

> lozf writes:

>> Gmail also had a big hand in the reduction of top posting, by hiding the quoted message by default (click the little '...' icon to see it).

>> This means that replies in-line, or below quoted text are instantly hidden and then you get complaints from the technically challenged who insist the email you sent was blank.

>> I tried to educate and fight back for a long time, but too many important things were lost to those who insist on writing right where the cursor appears instead of taking a moment to position it thoughtfully, and alas the rest is history.

>> Spivak writes:

>>> Top posting only won in places where everyone uses Outlook. Mailing lists still use quoted style.

>>> js2 writes:

>>>> We have lost this battle, but keep fighting the good fight. We've also lost to top-posting and JavaScript.

>>>> Sir_Cmpwn writes:

>>>>> Maybe the answer is to return to sending plaintext emails? HTML emails are an abomanation. Rather than extend them, just ditch them.


Some old-school lists might have a consistent style, but normal-people lists are more often than not top-quoted.

Almost all email clients default to top-quoting, and bottom quoting requires more work, because you need to cut out irrelevant parts. It's not easy to get people who have never bottom-quoted to start.


> We've also lost to top-posting and JavaScript.

While certain popular webmail clients push top-posting hard, I still see a lot more inline quoting in professional contexts, even where most users are using a client biased to top posting, than I see top posting.


top-posting still makes me sad.


Why? I grew up top posting (thanks to web mail clients), and personally I find having to scroll past tons of old messages in a thread to find the latest message is weird. Why is that preferred? I feel like I'm missing out on some big secret that top posting kills.

Edit: Ok, I found this: http://www.idallen.com/topposting.html

I'm convinced that 'bottom posting' is superior.


Emails can be automatically displayed in threads¹ and proper clients do so (e.g. Apple Mail) with the help of Message-ID and In-Reply-To headers. There are no reason to "hard-code" every previous message body into new message body when replying, i.e. quoting all the previous messages below/above your content. That's just plain stupid. Let the client do that for you in much better way.

If you need to give more context in your reply, you can quote a line or two in the above of your text. This is usually only needed for long messages. An example:

    > This is a snipped from the message being replied to, i.e. quote.
    > Just a line or two to give some context.

    This is your text, where you you address the above concern. [More text...]

    > Another quote regarding some other issue.

    Your text here. The rule of thumb is to keep the quote shorter than your text.
I know there exist many broken email clients, but the solution is not to adapt for them but just keep following good practises. That's the only way to get the bad clients fixed. In the long run, everything else leads to more broken situation.

[1] https://cr.yp.to/immhf/thread.html


Bottom posting would be okay but what opponents of top posting are advocating is "inline quoting", which makes reading long chains of emails absolutely exhausting and obfuscated.

Top posting won for a reason: it saves everyone a lot of time.


No, top posting won because of Outlook (and to a lesser extent due to web clients).

The main evidence for this is that where I work (and surely in other places well), people who use Outlook end up re-inventing inline quoting, badly. They write their answers inline and use coloring to distinguish them because Outlook has no proper quoting support.

And the reason is quite simple: if each mail in a thread is only a small number of sentences, then top posting is fine. However, when you're trying to do serious technical work via email, replying to specific points is necessary. Inline quoting is simply the best way of clearly indicating which part of the original email you're replying to.


> which makes reading long chains of emails absolutely exhausting and obfuscated.

How do you mean? I've seen bottom posting be essentially abused, by folks that quote the entire preceeding email (and even others before it) before typing their 1 line reply. Or worse, folks that quote a giant thread and insert 1-2 line responses throughout the quoting, which require the reader to hunt for them. It seems that those cases could have been avoided by just cherry picking & quoting only what you wanted to respond to.

Or is there some other situation you have in mind with your response?


> How do you mean?

Because you keep reading the same thing over and over again while all you want to do is read the new content:

    ===
    a
    ===
    > a
    b
    ===
    > > a
    > b
    c
    ===
Another problem with inline quoting is that people are often lazy and quote everything, which means you need to scroll down a lot to hunt down for the new content.


> Another problem with inline quoting is that people are often lazy and quote everything, which means you need to scroll down a lot to hunt down for the new content.

The problem with top posting is that people systematically quote everything.

Inline quoting is what you just did here. It is the natural way for a discussion. The only interest of top posting is if you add new people to a thread and for them, bottom posting would be far more legible.


> The problem with top posting is that people systematically quote everything

I'd say it's the other way around.

Top posting fixes the problem of people quoting everything since everything is put below the signature.

The problem with inline quoting is that people quote entire paragraphs, even when they only mean to respond to a single sentence. Which leads to deluges of quoted text you have to scroll and scroll through until you reach the new content.

With Gmail and a top posted email discussion, I can catch up with the entire discussion with "n", read a few lines, "n", read a few lines, ... With inline quoting, catching up on such a discussion is exhausting.


I find it quite amusing that you complain about inline quoting here while practicing it in a way entirely different to what you complain about.


Does no one else clear the quoted message entirely before replying? As far as I know every email client/webapp already threads messages. Including the same message multiple times just wastes space.


At least with javascript you have the power to just not run it. As with images: Just don't download them. If what message you received breaks, so be it.


If you only want a small part of the internet to work you can disable javascript.

Otherwise it is a huge pain.


> HTML emails are an abomanation.

They're a life saver. This is 2017, the least we can ask is that people take the time to use bold, italics, bullet points, tables, hyperlinks, and type faces to make their communications more cogent.

If you mean that "abuse of HTML" is an abomination, then yes, sure. But light use of HTML is extremely important today and my opinion of someone trying to communicate an important piece of information to me is directly related to how much care they have put into composing their email.


I disagree, not even bold face is needed for effective communication. Besides, if you send me a mail with all these features, it will either not be displayed at all by my mail program, or as garbage, or, if you're lucky, as plaintext.

But a markdown formatter that sends the plaintext part as markdown seems like the perfect solution for both worlds. I don't mind reading markdown, it's designed for being readable, and I also write it often.


The are plenty of good mua that display html emails well though, so it sounds like your choice to avoid receiving them properly; a choice you're entitled to but not an argument against allowing visually formatting and graphics in emails.


Of course it's my choice,and I've also set up clawsmail to display HTML mail by the press of a button. The point is that I'm not the only one. With plaintext mail you can reach everyone, with HTML mail only a fraction of that.

If you send HTML mails, they're simply more likely to land in the spam folder, where 80% of all HTML mails belong.


>With plaintext mail you can reach everyone, with HTML mail only a fraction of that. //

Any stats on that? I'd reckon you're in 5x9s territory for those that are reachable by HTML mail (vs. plaintext). Also I don't know about other mail clients but Thunderbird has a setting to send HTML email in plaintext too, choose your poison.

For me text based emails are far less common and are more often than not "Hi, my name Lena, I saw your info on Facebook and want to know you well [...]". Indeed the only non-spam plaintext emails I can recall are dev mailing list mails.


The thing about HTML emails is, different email clients support different things.

It's not HTML5 at all. If you want to do layouts, you must use tables. There are hacky things you have to do to display things correctly across all different types of clients.

You have tools like this: https://buttons.cm/ which generate abominable code for the sake of compatibility.

Also, Outlook uses the Word rendering engine to process HTML. It's janky, at best.


It's that supposed to be an argument against HTML emails? That some companies choose not to implement it for compatibility? Like, let's stop printing because companies are making proprietary cartridges and breaking compatibility??


Not some companies. All companies, including Google for Gmail, Yahoo for Yahoo mail, Microsoft for Outlook, etc have very limited support for HTML in their HTML rendering engines.

Instead of using floats and margins, you have to revert to using <table> for layouts. Otherwise, your emails just won't render correctly, much of the time.

It's not possible to support HTML fully in Webmail clients, either. Even without scripting, you could write an HTML email that overlays a malicious button on top of Gmail's web interface itself, and it would be too easy to phish people.


That's a confused message you're giving: you don't want the ability to put an ordered list and an image in an email because you can't get pixel-perfect rendering with the (a!) full HTML spec?


And yet HN doesn't support bold, bullet points, tables, and type faces and we communicate just fine.

YAGNI.


Just because we communicate just fine doesn't mean we couldn't communicate better. We communicate just fine with no punctuation and spelling mistakes, does that mean it's a good idea?

Bold, italics, lists and particularly, code snippets and verbatim text would make HN a lot easier to follow.


HN already can show (non-highlighted) code snippets

  like such
and it's a pain in the ass for anyone reading in small screens.


Walking moves you from place to place, yet some people like vehicles ...


Agree html was probably overkill to get the useful subset: links, images, and text formatting. I send code snippets all the time, and to get it syntax highlighted so anyone can read it, it has to be an image. Which means no one can copy it.

Links can be rendered from the text. But images and formatting is horrible.

Markdown seems like the format email should have used if it had existed.


This. Also: The unconverted markdown source is in itself already a nice way of formatting text/code/lists/headings/whatever. That's the whole point of markdown, no? So, yes, markdown rules, but because I can use it in plain text sources and benefit from it. Just never convert to html except on webpages.


Surely convert it to html if the client decides that's how they want it, otherwise leave as markdown?


Well, that should be a receivers end decision imo. The content is there, everyone is free to view it as they please. But in essence it's plain text, no html tag shenanigans (because that's a pain to read when unparsed) or, god forbid, javascript (because it's dangerous).


Yes, that's exactly what I meant by "client". I think the tricky issue in this case relates to links because they totally ruin the text when left untranslated (in much the same way that unparsed html does), but some would prefer to view the original URL. I'd possibly advocate a different format - e.g. surround text in square brackets, supply URLs in order, at bottom of text.


I do. All my emails are plain text.


How did you get that to happen? Almost all emails I send are text but close to 100% of everything I receive is html.


I always send plaintext emails. HTML mail continues to be nuisance. You don't need fancy formatting for daily text communication. But I can understand why marketing people like it...


Ah remember text/enriched? It’s a standard designed for rich text in emails.

I don’t think any major product uses it right now though, but I believe it’s supported by old versions of Apple Mail circa 2004.


At least with markdown you also gain a pretty good idea of how it will format in plain text clients as well.


Or you know, a standard that actually supports useful things like links.


Your mail client can render links in plaintext emails. It probably already does. Bonus: no hiding evil URLs behind phishing <a> tags!


You guys are seriously downvoting HTML? Have you ever worked in a business environent? Have you have used Outlook (the most popular e-mail client in the world)?

How do you support attachments in text? Do you assume every "link" is a link? Do you modify your own system for adding attachments and referencing them in the body?

Oh wait. Now we're re-inventing the exact same thing again that HN users apparently consider evil.


>Have you have used Outlook (the most popular e-mail client in the world)?

Popular != good. Outlook is awful.

>How do you support attachments in text?

You don't. This is a benefit.

>Do you assume every "link" is a link?

Sure?

>Do you modify your own system for adding attachments and referencing them in the body?

No, you don't do this at all.

Plain

fucking

text.


>Outlook is awful.

Yes. And any system that wants to REMOVE the incumbent, has to replace it with superior features.

I mean, what are you actually trying to argue for here? You literally just used Markdown to add emphasis to your post.

Are you going to use a less expressive communication format for your important business e-mails... when you clearly use Markdown for internet comments with complete strangers?

I know HN is full of startups but I can't be the only person who actually interacts with clients on a daily basis.


Just because Markdown is appropriate here doesn't mean it's appropriate for emails. Comments on internet threads are fundamentally different from emails.

If I wanted to emphasize in email I might use a very small subset of markdown's syntax (i.e. asterisks) but only as a coincidence - you know markdown is based on common plaintext email patterns, right?


> How do you support attachments in text?

Attachments are part of the MIME standard and are completely orthogonal to HTML email.


> How do you support attachments in text?

RFC 2045


From the HN guidelines:

Please don't comment about the voting on comments. It never does any good, and it makes boring reading.


"Standard" is arguable when it comes to email. Yes messages can use HTML, but it's hard to get HTML email to look consistent across different clients.


I can't praise MailMate[1] enough here: A lean, no-fuss mac email client with first-party support for Markdown (with syntax highlighting!), and plenty of other goodies.

Cherry on top, its developer is very active, and keeps a regularly-updated blog[2], talking about email server quirks and many other interesting technical bits.

Note that I'm not in any way affiliated with the software – just a very happy customer.

[1]: https://freron.com

[2]: https://blog.freron.com


Thanks for sharing! I wanted to get more information, but couldn't find it on the website (mobile, without downloading), until I found this series of screencasts. https://m.youtube.com/#/watch?list=PLC4ZkBr87CO0jmrQvGQ77t44...

Looks very interesting for power users. Going to check this out!


Second MailMate. I wish I could swap out the parser for Kramdown... but it is leaps beyond Mail.app in utility!


Is it really easier to use markdown than bolding things using a keyboard shortcut?

And tables are downright awful in markdown (or anything barring a full spreadsheet editor). When would you want to do this by hand?


> Is it really easier to use markdown than bolding things using a keyboard shortcut?

Yes, it absolutely is easier to type a few asterisks in running text rather than selecting text, hitting a keyboard shortcut or clicking a button, and then going back to typing more text.


Most rich text editors allow bolding running text. "Ctrl+B" vs. "shift-8" are equal.

(Most rich text editors are poorly implemented and suffer from hidden state, but that's a separate problem.)


I use Ctrl+B in my browser to open the bookmarks side-panel though.


In my opinion, it is about the same, maybe easier to not use markdown. If we count keystrokes, it’s less.

If already typed, it’s less keystrokes to select with Shift+Ctrl then press Ctrl+B.

If it’s not typed, it’s less keystrokes to Ctrl+B at he start and end.

For italics, the keystrokes are about the same with and without markdown.


Perfectly reasonable to have both available: type markdown along the way, map keyboard shortcuts to insert the appropriate formatting characters whether used statefully or with text selected.


I seem to remember that typora works that way.


Hmmm. To be fair you could also use ctrl+b instead of the markdown sequence.


That's an interesting flow but I couldn't imagine typing like that, formatting while I typed would totally interrupt the thought process/message I'm trying to get out.

My flow is to type first just to get the thoughts out then I format last while I proofread.


I do occasionally go back and add formatting, especially when writing a longer article. I also often add links later, or write [link text]() and fill in the URL later so I don't have to stop and find a reference I know exists. But I add certain types of formatting immediately, in much the same way that when speaking I emphasize certain words in a sentence.


I've used it for general composition (headings, bold text, etc), but its killer feature is for when you want to include a block of highlighted code. Markdown Here has fantastic support for GFM fenced code blocks.

I wish I could use it in Jira. :-(


I ran into the same issue and found https://chrome.google.com/webstore/detail/markdown-to-jira/j...

That converts markdown to Jira-markdown and back again. It's been fantastic for me.


I find tables far easier in md than anywhere else. You can distill them down to:

    Head | Head
    ---|---
    Row | row
    Row | row
Etc.


Markdown tables are reasonably lightweight and are very easy to generate with regex substitution off a delimited datastream. Say, tabs:

    s/^/| /; s/\t/ | /; s/^/ |/
Add your header and alignment block and you're set.


For those wondering which of the thousand bespoke dialects of Markdown this speaks, this project uses marked.js: https://github.com/chjj/marked


marked.js has a GFM option, which is what Markdown Here appears to be using: https://github.com/adam-p/markdown-here/blob/dc1454ecb26a951...

I guess these days most projects use GitHub markdown since it's the most common and with the best documentation.


It's not quite so simple. Markdown's problem is that it's always been pretty ill-specified. The original GFM was merely an extension to "Markdown", with its myriad of implementations all with differing behaviors. Even the marked.js README says that it merely "more or less passes the official markdown test suite"; which tests doesn't it pass? And what official Markdown test suite is this referring to ("official" would imply that it's from John Gruber himself, but the first Google result for "official markdown test suite" doesn't have Gruber's name on it)?

Of course nowadays we have CommonMark, but despite ongoing activity CM has yet to have a 1.0 release, meaning that even if one intended to adhere to CM, ongoing maintenance would be required to ensure compatibility. Given that it looks as if marked.js last had a release in mid-2015, that would lead one to assume that it's not trying to follow CM. Furthermore, it was in March of this year that GFM was officially redefined to be an extension of CommonMark, not of Markdown: https://github.github.com/gfm/ , so it's unclear which version of GFM marked.js is emulating.

Lest anyone think I'm taking this too seriously though, the project here in the OP almost certainly doesn't need to care about compatibility. The markup produced is completely transient, so the worst that would happen upon hitting an unintended edge case would just be some temporary cursing on the part of the user. Where it actually matters is when you're storing the markup long-term and expect to ever want to upgrade your Markdown parser without breaking everything; for an example of the difficulty here, see how Rust has been attempting to gracefully upgrade the parser in rustdoc for almost a year now: https://internals.rust-lang.org/t/what-to-do-about-pulldown-... , https://github.com/rust-lang/rust/issues/44229


It's a superset of Marked's GFM mode, since MDH also supports TeX math.

MDH-specific cheatsheet here: https://github.com/adam-p/markdown-here/wiki/Markdown-Here-C...


So markdown was inspired by the was emails were formated in plain texts, which was easily read by humans, just so that eventually through permutations, variations and abominations people start converting this (onnce) easily readable syntax into HTML emails?

great.


That's because browsers don't support native Markdown formatting.


Markdown is it's own formatting environment! All it needs is a constant-width font, a concept not particularly new to the world of computers.

If there were no downsides to this, and email was build from the first day on to work with HTML, then this would all be fine, but sadly (or not so sadly) this isn't the case.


I love Markdown Here and if the author is reading this — thanks a lot for your work. I've had a great time using it for years.

I've did had problems with it when using it with FastMail and I hope it gets fixed at some point. Naturally it's optimized for Gmail first.

Btw folks, webmail isn't the only option. I've been using MailMate (https://freron.com/), it has baked-in Markdown support, keyboard shortcuts, plays well with Gmail too and it's awesome.

For messages it's much better to use a client like MailMate instead of a browser plugin like Markdown Here, because it will properly format and send multi-part mime messages — your message will be displayed well in both text and HTML ;-)

PS: I wish an open-source alternative would be as awesome as MailMate, but alas. On the other hand MailMate is very standards oriented and I don't mind supporting its author with money.


Create an issue with what's going wrong with FastMail. https://github.com/adam-p/markdown-here/issues/new

My own brief testing -- and another user's report -- suggests that it's working. Make sure you have rich editing enabled.


You forgot the small print: MailMate is Mac only.


Yes, sorry, but it's really good, I wish Thunderbird were like that.


Worth noting: Requires "Access [to] your data for all websites"

On the add-on site, it fortunately does note why:

> Privacy: Markdown Here accesses and modifies web content when you activate it. It can, in theory, access other web content, but does not. It also makes no Internet requests whatsoever. Your data is modified when and where you choose, and does not leave your browser.

Is this a limitation of WebExtension APIs that necessitate this? Perhaps there is an opportunity for more granular WebExtension APIs.


This is essentially a limitation of the browser environment itself, not of WebExtensions. Allowing an extension to inject code into a web page gives that extension the ability to do anything that the page could do on its own, including exfiltrating data. I don't see any easy way to prevent this without severely limiting what the extension can do.


It could at least be limited to gmail.com or the browser could ask for each domain.


You want a confirmation box for every website you access?


The box should only appear when I try to toggle Markdown for the first time (which I would only do for web mail).

If I understand it correctly, as it is now the extension has access to everything on every website I visit.


You could maaaaybe convince me to say something like: "all content stored in [textarea] blocks" or "input type=password" CSS-type scoping, but fundamentally, it wants to rewrite _your_ content on a page, but that requires it is allowed to view and modify _all_ content of the page.


What's the point? My plain-text emails are already awesome.


Images. Formatted text. Syntax highlights in source code snippets.

Html is overkill for these things, but still better at them than plaintext. Markdown strikes a good balance.


Images in emails? Are you serious?


The more I read this thread, the more I think I live in a different universe.

Yes, images, bold, links, colors and font sizes is what I see in all the emails I get (and send).

I sometimes get the odd plaintext email and wonder why the sender was punished.

I started using email in 1991. The mail today (with all the civilized elements) is infinitely better.


Syntax highlighting for code blocks


You may not like it, but still. If you can’t understand the code w/o syntax highlighting, you are using a wrong language.


I think code is always understandable without highlighting. It's just harder. It's like text is almost always understandable without proper casing but it's harder to read.

The first alternative to highlighted syntax is an IMAGE with the same code, with highlighting.


I can still understand it without. It's just nicer with :)


> It can:

> * Read and change all your data on the websites you visit

https://github.com/adam-p/markdown-here/blob/master/src/mani...

Shouldn't this just be email serving domains? e.g. `https://mail.google.com` et al? Also it'd be great if the Chrome webstore could offer some verification, so that as long as I trust Github and Google, I can confirm that the code I see at Github is the extension I'm installing.


> Shouldn't this just be email serving domains?

That was my initial idea, but then I realized that it can work in more places than I ever would have guessed. And I/we wouldn't have discovered them if it were only whitelist-enabled.

You can see dozens of the sites here, and there are surely many more: https://github.com/adam-p/markdown-here/wiki/Compatibility

> Also it'd be great if the Chrome webstore could offer some verification

I agree, in principle. Unfortunately, it wouldn't match. At some point Mozilla decided to start rejecting updates because there was unreachable -- Chrome-only -- code in the extension. So I had to start using a preprocessor during builds to strip out platform-specific stuff. (AMO's reviews have driven me nuts over the years.)

The build is reproducible, though.

I also provide instructions for running the extension directly from source. Chrome makes it easy (Firefox doesn't). https://github.com/adam-p/markdown-here#manualdevelopment

(I just realized that I need to update the Firefox instructions/link for WebExtensions. Which is even more painful than XUL was to use from source.)


Chrome extensions are stored unpacked on your filesystem, it's easy to read what code is being used. On OSX they're in:

    ~/Library/Application Support/Google/Chrome/Default/Extensions



Very neat idea and execution, but I doubt its usefulness. Let me explain what my thinking would be if I was the developer:

Whatever email client you're using likely has easier/better support for bold/italics or other forms of text styling very easily, with shortcut keys. It probably also supports numbered/bullet lists automatically by converting lines that start with 1., 2., ... or */- characters, too.

If you think about it, there's not a lot more features of Markdown remaining. The email client also likely allows easier ways to insert pictures and create links, too.

This leaves us with:

- Tables: I suspect anyone actually writes tables in markdown, also the mail editors probably support this better.

- Math equations: I suspect anyone actually uses this except academics.

- Code blocks with syntax highlighting: this seems to be the only useful feature of the extension.

I also realized the extension does not work on Google Docs, where I was mainly hoping to use the code formatting feature.


> I doubt its usefulness

Tell that to the 70k people who use it in Chrome alone.[0] While for you it's not that useful, I've used it for years now.

I'd say Adam has built the perfect product for the target market.

[0]: https://chrome.google.com/webstore/detail/markdown-here/elif...


I blog in markdown, I reddit in markdown, I trello in markdown, I github in markdown. I write books in markdown. It's become my writing method of choice. This is for me. I'm so glad reddit doesn't have that ugly, clunky, icon bar to let me bold or hyperlink. I'm so glad trello doesn't either.


Good luck finding support for code highlighting with this approach. Markdown Here is unbeatable for this.


I find this nicely ironic, as Markdown was invented as a way to convert the de-facto standard for writing textual messages (like email and usenet) with semantic information.

Personally, I have been writing my emails in Markdown for years, as I still use a fixed-width font even in Gmail (which doesn't have a text-only option, at least not that I know of).

EDIT: I just checked, and Gmail does have a plain-text option. However, for double irony, when you select it the font used for the message is not fixed-width, which pretty much beats the purpose. :-/


Yeah I hear ya. I used to have a browser extension that let me have a fixed width font and use plain text mode in Gmail, but I think that stopped working a couple years ago. These days, if I am writing a long email, I usually just type it in vim first.


Would be great if you had this for Outlook. My work emails are where I would need this the most.


https://github.com/adam-p/markdown-here/issues/67

I probably won't do it, though. I'm pretty sure I'd have to reimplement the entire thing in .NET.


If I could get something that would make Outlook just copy and paste text in a consistent way, I'd pay money for it. There are supposed to be settings for that, but I'm apparently not smart enough to figure out how they work (or if they work).


I've found out that even business types can understand text/plain emails with markdown-style formatting, so what exactly is the usecase for this?


While \this\ is understandable, it is a lot less professional than italic text. It's all about presentation, and this is a shortcut to a better presentation with the same amount of effort.


That probably depends on whether you want to convey meaning by formatting of free flowing text. Professional way to do that is to highlight (highlight, not make bold, italics or whatever) the parts of your email that constitute the tl;dr part, even more professional is to simply write your email such that it's main point is repeated in first and/or last paragraph.


AFAIK there's no way to escape asterisks on HN. Backslashes certainly don't work. :(


Because you can use this plugin for more than just emails. I've used this in a lot of backend systems that support rich-text interfaces but don[t support markdown.


If anyone has set something like this up with emacs, would love to hear about it. I'm currently using org-mime, but would prefer to use markdown

Edit: 30 seconds of searching led me to here: http://tess.oconnor.cx/2008/01/html-email-composition-in-ema...


Just curious: why do you prefer markdown over org?


I'm more familiar with markdown, and I think for non-emacs users the plain text format is more familiar as well


This is pretty cool. If the main interface here is to allow you to right click and transform the text though, does this require permissions to read and change all data on all your pages? Can the right click menu not only look at just the highlighted portion? Permissions feel excessive, but not sure if this is the only way based on how Chrome enables it.


This is fantastic! I tried it in Thunderbird and it works great. Just keep in mind that math formulas are sent to be rendered via Google Charts - so don't use this to generate your super-secret cold fusion equations... (as if sending them by mail would be a great idea to begin with).


Cheers to Adam. I've been using the for years--since time the extension was called "Markdown Anywhere" and had a purple butterfly as the logo and mascot!

My use cases:

- Sending code, diffs, and equations in emails

- Copy/paste from other markdown docs

- Dodging crappy WYSIWGs on some sites


I've been using this extension for a while now and I'm really loving it.

Whenever I need to send an email that includes a code sample, Markdown Here makes it so much better than just slapping a monospaced font on plaintext code.


By indenting for you?


No, it doesn't format the code, but it does support syntax highlighting.


Been using Airmail for macOS for a few years now. Pretty happy with it, does formating with Markdown as well.


This is great. I'm often asked to provide data, and have made some helper methods to return the data in markdown. I then typically have to find a converter before pasting the results into the email body, so having an extension to make this easier is great :D


This looks like a fun TodoMVC equivalent for testing addons, I think I might try to roll my own!


I've been using this for a few years now, mainly with FastMail and Gmail. I can't live without it, especially for sending emails with documentation, technical instructions, usernames, etc. to customers.


As if HTML email was not an idiotic thing already, you build a tool to create HTML emails from a text format that was based on the usual formatting of plain text emails (and also is less portable than assembly).


Such an amazing extension. It makes writing email fun again.


95% of the email I send is unstyled. Occasionally I’ll throw in bold text. Does this really solve a problem for the everyday man or woman?


It only makes sense if an email is "unstyled". Thunderbird manages to fuck up my email layout all the time if I need to add a few lines of preformated text, occasional bullet list or some highlighting. If I try to write plaintext-only emails it fucks up RE: and FWD: emails for most normal people. If I use "rich" text emails with standard settings email client will do everything to fuck them up and while it will look ok on my screen it will end up with some smart-ass who uses plaintext-only client whining about me writing shitty formated emails.

So, I don't know if using this plugin will feel helpful (I doubt it, since second most used formatting option for me is text-highlighting with color — indispensable when marking up some airline fare construction quote or something else cryptic enough, — which markdown doesn't really support), but the problem it tries to solve definitely exists.


Does this support ProtonMail? I'm interested, but I'm also a bit paranoid with my mail privacy.



Doesn't seem to work with fastmail


I just quickly tested and it still seems to work. Make sure you have rich editing enabled[1]. If it still doesn't work, create an issue with more info.

[1]: https://github.com/adam-p/markdown-here/wiki/Compatibility#f...


It seems I needed to reload the page. Works great now, thanks.


I'd like to use it with fastmail in firefox


I can do that very simply. Just start writing. But please, don't parse that and send html emails.


This is vulnerable to XSS, payload: [Click Me](javascript:this;alert(document.domain&#41;)


Or even the more naive "<script>alert(3)</script>" - which was the second thing I tried.


Are there any mail clients that can send with Content-Type: text/markdown?


That would be nice if it was standard for clients to display text/markdown rendered as styled text. This would require an actual standard for the markdown syntax though. Without the rendering, markdown is just text/plain.

Are there any mail clients that will send both the markdown source and the rendered HTML as a multi-part message?



Ok, good to know, thanks. The point still stands that the receiver's client probably doesn't bother styling the message. I mean even if GMail, say, was persuaded to do it, Outlook for instance wouldn't.


Doesn't seem to work with Google Inbox. Agh.


It does not. Here's an Github issue I've created almost 2 years ago...

https://github.com/adam-p/markdown-here/issues/327#issuecomm...


Does this work through the Apple mail app ?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: