Markdown Here – Write email in Markdown
markdown-here.com
markdown-here.com
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! :)
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.
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.
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 )
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!
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.
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?
It looks pretty!
It's not super high priority, but someday...
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...
[1]: https://github.com/adam-p/markdown-here/tree/markdown-it
# DO NOT ET CETERA
...And then render.
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.
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.
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.
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?
RFC 2045
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
Attachments are part of the MIME standard and are completely orthogonal to HTML email.
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.
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.
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.
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.
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.
100a I must express myself clearly when posting. <return><esc>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.
Edit: Ok, I found this: http://www.idallen.com/topposting.html
I'm convinced that 'bottom posting' is superior.
Top posting won for a reason: it saves everyone a lot of time.
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?
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
===
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.
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.
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.
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.
Otherwise it is a huge pain.
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.
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.
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.
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.
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.
YAGNI.
Bold, italics, lists and particularly, code snippets and verbatim text would make HN a lot easier to follow.
like such
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.
If you send HTML mails, they're simply more likely to land in the spam folder, where 80% of all HTML mails belong.
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.
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.
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
Looks very interesting for power users. Going to check this out!
And tables are downright awful in markdown (or anything barring a full spreadsheet editor). When would you want to do this by hand?
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 are poorly implemented and suffer from hidden state, but that's a separate problem.)
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.
My flow is to type first just to get the thoughts out then I format last while I proofread.
I wish I could use it in Jira. :-(
That converts markdown to Jira-markdown and back again. It's been fantastic for me.
s/^/| /; s/\t/ | /; s/^/ |/
Head | Head
---|---
Row | row
Row | row
I guess these days most projects use GitHub markdown since it's the most common and with the best documentation.
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
MDH-specific cheatsheet here: https://github.com/adam-p/markdown-here/wiki/Markdown-Here-C...
great.
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'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.
My own brief testing -- and another user's report -- suggests that it's working. Make sure you have rich editing enabled.
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.
If I understand it correctly, as it is now the extension has access to everything on every website I visit.
The first alternative to highlighted syntax is an IMAGE with the same code, with highlighting.
Html is overkill for these things, but still better at them than plaintext. Markdown strikes a good balance.
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.
> * 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.
~/Library/Application Support/Google/Chrome/Default/Extensionshttps://gist.github.com/chittti/6f59b53053c44954414ff15d5826...
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.)
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.
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...
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. :-/
I probably won't do it, though. I'm pretty sure I'd have to reimplement the entire thing in .NET.
Edit: 30 seconds of searching led me to here: http://tess.oconnor.cx/2008/01/html-email-composition-in-ema...
My use cases:
- Sending code, diffs, and equations in emails
- Copy/paste from other markdown docs
- Dodging crappy WYSIWGs on some sites
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.
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.
[1]: https://github.com/adam-p/markdown-here/wiki/Compatibility#f...
Are there any mail clients that will send both the markdown source and the rendered HTML as a multi-part message?
Source:
https://tools.ietf.org/html/rfc7763
https://www.iana.org/assignments/markdown-variants/markdown-...
https://github.com/adam-p/markdown-here/issues/327#issuecomm...