adam-p / markdown-here

Google Chrome, Firefox, and Thunderbird extension that lets you write email in Markdown and render it before sending.

Markdown Here

Visit the website.
Get it for Chrome.
Get it for Firefox.
Get it for Safari.
Get it for Thunderbird and Postbox.
Get it for Opera.
Discuss it and ask questions in the Google Group.

Markdown Here is a Google Chrome, Firefox, Safari, Opera, and Thunderbird extension that lets you write email^† in Markdown^‡ and render them before sending. It also supports syntax highlighting (just specify the language in a fenced code block).

Writing email with code in it is pretty tedious. Writing Markdown with code in it is easy. I found myself writing email in Markdown in the Github in-browser editor, then copying the preview into email. This is a pretty absurd workflow, so I decided create a tool to write and render Markdown right in the email.

To discover what can be done with Markdown in Markdown Here, check out the Markdown Here Cheatsheet and the other wiki pages.

^{†: And Google Groups posts, and Blogger posts, and Evernote notes, and Wordpress posts! See more.
‡: And TeX mathematical formulae!}

Table of Contents

Installation Instructions
Usage Instructions
Troubleshooting
Compatibility
Notes and Miscellaneous
Building the Extension Bundles
Next Steps, Credits, Feedback, License

Installation Instructions

Chrome

Chrome Web Store

Go to the Chrome Web Store page for Markdown Here and install normally.

After installing, make sure to reload your webmail or restart Chrome!

Manual/Development

1. Clone this repo.
2. In Chrome, open the Extensions settings. (Wrench button, Tools, Extensions.)
3. On the Extensions settings page, click the "Developer Mode" checkbox.
4. Click the now-visible "Load unpacked extension…" button. Navigate to the directory where you cloned the repo, then the src directory under that.
5. The Markdown Here extension should now be visible in your extensions list.
6. Reload your webmail page (and maybe application) before trying to convert an email.

Firefox and Thunderbird

Mozilla Add-ons site

Go to the Firefox Add-ons page for Markdown Here and install normally.

Or go to the "Tools > Add-ons" menu and then search for "Markdown Here".

After installing, make sure to restart Firefox/Thunderbird!

Note: It takes up to a month for Mozilla to approve changes to the Firefox/Thunderbird extension, so updates (features, fixes) will lag behind what is shown here. You can manually choose to install the newest version before it's reviewed from the list of versions: https://addons.mozilla.org/en-US/firefox/addon/markdown-here/versions/

Manual/Development

1. Clone this repo.
2. Follow the instructions in the MDN "Setting up an extension development environment" article.

Safari

Download the extension directly. When it has finished downloading, double click it to install.

Preferences

To get to the Markdown Here preferences, open the Safari preferences and then go to the "Extensions" tab. Then click the "Click me to show Markdown Here options" box.

Opera

Note that Markdown Here only works with Opera versions 16 and higher (i.e., the ones that are based on Chromium).

Go to the Opera Add-ons store page for Markdown Here and install normally.

After installing, make sure to reload your webmail or restart Chrome!

Usage Instructions

Install it, and then…

1. In Chrome/Safari/Opera, make sure you reload your web mail page before trying to use Markdown Here.

2. In Chrome/Firefox/Safari/Opera, log into your Gmail, Hotmail, or Yahoo account and start a new email. In Thunderbird, start a new message.

3. Make sure you're using the rich editor.

   • In Gmail, click the "Rich formatting" link, if it's visible.
   • In Thunderbird, make sure "Compose messages in HTML format" is enabled in your "Account Settings", "Composition & Addressing" pane.

4. Compose an email in Markdown. For example:

   **Hello** `world`.
   
   ```javascript
   alert('Hello syntax highlighting.');
   ```
   

5. Right-click in the compose box and choose the "Markdown Toggle" item from the context menu. Or click the button that appears in your address bar. Or use the hotkey (CTRL+ALT+M by default).

6. You should see your email rendered correctly from Markdown into rich HTML.

7. Send your awesome email to everyone you know. It will appear to them the same way it looks to you.

Revert to Markdown

After rendering your Markdown to pretty HTML, you can still get back to your original Markdown. Just right-click anywhere in the newly rendered Markdown and click "Markdown Toggle" -- your email compose body will change back to the Markdown you had written.

Note that any changes you make to the pretty HTML will be lost when you revert to Markdown.

In Gmail, you can also use the browser's Undo command (CTRL+Z / CMD+Z, or from the Edit menu). Be warned that you might also lose the last few characters you entered.

Replies

In Gmail, Thunderbird, and Google Groups, you can use "Markdown Toggle" normally: just write your reply (top, bottom, inline, wherever) and then convert. The original email that you're replying to will be left alone. (Technically: Existing blockquote blocks will be left intact.)

In Hotmail and Yahoo (which don't put the original in a blockquote), and optionally in Gmail, Thunderbird, and Google Groups, you can ensure that only the part of the reply that you wrote gets converted by selecting what you want to convert and then clicking "Markdown Toggle" -- see the next section.

Selection/Piecemeal Conversion

Sometimes you don't want to convert the entire email; sometimes your email isn't entirely Markdown. To convert only part of the email, select the text (with your mouse or keyboard), right-click on it, and click the "Markdown Toggle" menu item. Your selection is magically rendered into pretty HTML.

To revert back to Markdown, just put your cursor anywhere in the block of converted text, right click, and click the "Markdown Toggle" menu item again. Now it's magically back to the original Markdown.

Things to know about converting/reverting a selection

• If you select only part of a block of text, only that text will be converted. The converted block will be wrapped in a paragraph element, so the original line will be broken up. You probably don't want to ever do this.

• You can select and revert multiple converted blocks at the same time. One upshot of this is that you can select your entire email, click "Markdown Toggle", and all portions of it that you had converted will be reverted.

• If you don't have anything selected when you click "Markdown Toggle", Markdown Here will check if there are converted blocks anywhere in the message and revert them. If there no converted blocks are found, it will convert the entire email.

Options

The Markdown Here Options page can be accessed via the Chrome, Firefox, Safari, or Thunderbird extensions list. The available options include:

• Styling modifications for the rendered Markdown.
• Syntax highlighting theme selection and modification.
• TeX math formulae processing enabling and customization.
• What the hotkey should be.

For Chrome and Firefox, any changes made in the Markdown Here Options are automatically synchronized between your other installations of that browser (if you have the sync feature enabled in the browser).

Troubleshooting

See the Troubleshooting wiki page.

Compatibility

See the Compatibility wiki page.

Notes and Miscellaneous

• Markdown Here uses Github Flavored Markdown, with the limitation that GFM special links are not supported (issue #11); nor will they be, as MDH is not Github-specific.

• Available languages for syntax highlighting (and the way they should be written in the fenced code block) can be seen on the highlight.js demo page.

• Images embedded inline in your Markdown will be retained when you "Markdown Toggle". Gmail allows you to put images inline in your email -- this can be much easier than referencing an external image.

• Email signatures are automatically excluded from conversion. Specifically, anything after the semi-standard '-- ' (note the trailing space) is left alone.

  • Note that Hotmail and Yahoo do not automatically add the '-- ' to signatures, so you have to add it yourself.

• The "Markdown Toggle" menu item shows up for more element types than it can correctly render. This is intended to help people realize that they're not using a rich editor. Otherwise they just don't see the menu item and don't know why.

• Styling:

  • The use of browser-specific styles (-moz-, -webkit-) should be avoided. If used, they may not render correctly for people reading the email in a different browser from the one where the email was sent.
  • The use of state-dependent styles (like a:hover) don't work because they don't match at the time the styles are made explicit. (In email, styles must be explicitly applied to all elements -- stylesheets get stripped.)

• For more tweaky features, visit the Tips and Tricks section.

Building the Extension Bundles

cd utils
node build.js

Chrome and Opera extension

Create a file with a .zip extension containing these files and directories:

manifest.json
common/
chrome/

Firefox/Thunderbird extension

Create a file with a .xpi extension containing these files and directories:

chrome.manifest
install.rdf
common/
firefox/

Safari extension

The browser-specific code is located in the markdown-here-safari project.

Use the Safari Extension Builder.

Next Steps

See the issues list and the Notes Wiki. All ideas, bugs, plans, complaints, and dreams will end up in one of those two places.

Feel free to create a feature request issue if what you want isn't already there. If you'd prefer a less formal approach to floating an idea, post to the "markdown-here" Google Group.

It also takes a fair bit of work to stay up-to-date with the latest changes in all the applications and web sites where Markdown Here works.

Credits

Markdown Here was coded on the shoulders of giants.

• Markdown-to-HTML: chjj / marked
• Syntax highlighting: isagalaev / highlight.js
• HTML-to-text: mtrimpe / jsHtmlToText

Feedback

All bugs, feature requests, pull requests, feedback, etc., are welcome. Create an issue. Or post to the "markdown-here" Google Group.

License

Code

MIT License: http://adampritchard.mit-license.org/ or see the LICENSE file.

Logo

Copyright 2015, Austin Anderson. Licensed to Markdown Here under the MDH contributor license agreement.

Other images

Creative Commons Attribution 3.0 Unported (CC BY 3.0) License

---

markdown-here's Issues

Fails to parse Github flavored markdown example (chrome extension)

I noticed in the description that you say it uses Github Flavored Markdown. But when I copied their test markdown document (found here) into Gmail using the Chrome extension, all I get is a jumbled mess:

GitHub Flavored Markdown ================================ View the source of this content. Let's get the whole "linebreak" thing out of the way. The next paragraph contains two phrases separated by a single newline character: Roses are red Violets are blue The next paragraph has the same phrases, but now they are separated by two spaces and a newline character: Roses are red Violets are blue Oh, and one thing I cannot stand is the mangling of words with multiple underscores in them like performcomplicatedtask or dothis_and_do_that_and_another_thing. A bit of the GitHub spice ------------------------- In addition to the changes in the previous section, certain references are auto-linked: SHA: be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2 User@SHA ref: mojombo@be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2 User/Project@SHA: mojombo/god@be6a8cc1c1ecfe9489fb51e4869af15a13fc2cd2 #Num: #1 User/#Num: mojombo#1 User/Project#Num: mojombo/god#1 These are dangerous goodies though, and we need to make sure email addresses don't get mangled: My email addy is [email protected]. Math is hard, let's go shopping ------------------------------- In first grade I learned that 5 > 3 and 2 < 7. Maybe some arrows. 1 -> 2 -> 3. 9 <- 8 <- 7. Triangles man! a^2 + b^2 = c^2 We all like making lists ------------------------ The above header should be an H2 tag. Now, for a list of fruits: Red Apples Purple Grapes Green Kiwifruits Let's get crazy: 1. This is a list item with two paragraphs. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam hendrerit mi posuere lectus. Vestibulum enim wisi, viverra nec, fringilla in, laoreet vitae, risus. Donec sit amet nisl. Aliquam semper ipsum sit amet velit. 2. Suspendisse id sem consectetuer libero luctus adipiscing. What about some code in a list? That's insane, right? 1. In Ruby you can map like this: ['a', 'b'].map { |x| x.uppercase } 2. In Rails, you can do a shortcut: ['a', 'b'].map(&:uppercase) Some people seem to like definition lists

Lower cost
The new version of this product costs significantly less than the previous one!
Easier to use
We've changed the product so that it's much easier to use!
I am a robot ------------ Maybe you want to print robot to the console 1000 times. Why not? def robot_invasion puts("robot " 1000) end You see, that was formatted as code because it's been indented by four spaces. How about we throw some angle braces and ampersands in there?
© 2004 Foo Corporation
Set in stone ------------ Preformatted blocks are useful for ASCII art:
              ,-.      ,     ,-.   ,-.     / \   (   )-(   )     \ |  ,.>-(   )-<      \|,' (   )-(   )       Y -'   -'       |//   `-'       |       |       |    -hrr-    _|_  
Playing the blame game ---------------------- If you need to blame someone, the best way to do so is by quoting them: > I, at any rate, am convinced that He does not throw dice. Or perhaps someone a little less eloquent: > I wish you'd have given me this written question ahead of time so I > could plan for it... I'm sure something will pop into my head here in > the midst of this press conference, with all the pressure of trying to > come up with answer, but it hadn't yet... > > I don't want to sound like > I have made no mistakes. I'm confident I have. I just haven't - you > just put me under the spot here, and maybe I'm not as quick on my feet > as I should be in coming up with one. Table for two -------------
ID  Name    Rank
1   Tom Preston-Werner  Awesome
2   Albert Einstein Nearly as awesome
Crazy linking action -------------------- I get 10 times more traffic from [Google] [1] than from [Yahoo] [2] or [MSN] [3]. [1]: http://google.com/ "Google"   [2]: http://search.yahoo.com/ "Yahoo Search" [3]: http://search.msn.com/ "MSN Search"

I would check to make sure that your Markdown --> HTML parser is in fact compliant with GFM, because it seems that it may only support certain aspects of the markdown syntax.

Extension updates not being accepted by Mozilla

Version 2.1.0 was submitted to Mozilla (aka addons.mozilla.org, aka AMO) May 31, 2012. It was preliminarily reviewed some time after that and became available for direct download. Because the review was only "preliminary" and not "full", the extension can't be searched for (they need a direct link) and users receive a dire warning when they try to install it.

With the following releases I tried to get a full review done. The review queue takes forever (~1 month) to get through, and if you submit a new version you get put back to the end of the queue (I found out the hard way).

I'll keep this issue updated with info about efforts to get Markdown Here fully reviewed and accepted by AMO.

Note that this issue supersedes issue #20: "Firefox extension not available anymore".

Firefox: Email content sometimes lost when sending

Reproduction, maybe:

1. In Firefox, in Gmail. (Not sure about other webmail clients. Doesn't seem to happen in Chrome.)
2. Have a signature (not sure if that's necessary).
3. Set yourself as the recipient for the email. Put whatever in the subject.
4. Type some trivial Markdown in the body. Without moving the cursor or anything, hit the Markdown Here hotkey. You should see that the body of the email is oddly large and the sig suddenly has a serif font.
5. Send the email.
6. View the sent email. It has a sig but is missing the MD body you typed.

When viewing the DOM after the rendering, it appears that the markdown-here-wrapper is ending up as a direct child of the html element, instead of the body element -- but the sig is staying in the body.

I don't have any other info or insight into this right now, but I'll look into it soon. It's very bad.

Cannot modify math formulas after saving to evernote

Seems that once math formulas are saved in evernote and after reopening it for editing, the math formulas cannot be toggled.

I think maybe the reason is due to evernote itself will modify the image tag but do not know what exactly causes the problem.

Thanks for this great project :)

Restore cursor position after reverting

To avoid user confusion and ease workflow, the cursor position should be restored after reverting rendered Markdown.

Idea: Serialize the selection information to another data- attribute in the wrapper.

Any chance there could be a Safari extension, too?

I use Safari for work-related Wordpress blog posts. Would be nice to use this!

would it be possible to implement (a subset of) pandoc markdown extensions?

The extension works great and is really, really useful; I'm wondering though, if you'd be willing to implement (a subset of) pandoc extensions?

I'm specifically interested in extensions for lists, tables and footnotes. (Unfortunately, javascript is definitely not my forte.)

When selecting whole text - don't paragraph it

When selecting whole text in the box (eg. ctrl/cmd + a) and using markdown - don't paragraph the selection - that would make it easier for Mac users to use the addon, no need to click in empty spaces. And makes sense as a whole.

<span> tags still visible in 2.3.1 (after #17 fixed)

Example:

<span class="Apple-tab-span markdown-here-exclude" style="white-space:pre">    </span>Wait( 5 );

Tools->Extensions shows version 2.3.1 installed. Have deinstalled, killed Chrome, and restarted, and reinstalled to make sure I definitely have the new version.

Have tried copying code from code editor into notepad before pasting into gmail to ensure it's as plain as possible, but it does just seem to be the tabs doing it.

HTML-to-plaintext fails for <pre> text

Reproduction

1. Go here or to any "raw" source page for a Github README (like ours).
2. Select-all, copy.
3. Paste into Gmail.
4. Click "Markdown Toggle".

Result: Pretty disastrous rendering. Specifically, it mostly looks like the whole text is being treated as a single line.

Preliminary diagnosis

jsHtmlToText (the library we use for HTML-to-plaintext) adds newlines to text based on tags, and doesn't pay attention to stuff like white-space: pre; -- which changes how newlines should be treated.

Possible solutions

• Make the HTML-to-plaintext processing more intelligent. E.g., check styles like white-space.
• Make the HTML-to-plaintext processing simple: just use innerText (or textContent in Gecko). It'll require proper testing, but some initial fooling around suggests it works well.

Workaround

Don't paste <pre> text. Paste plaintext or convert to plaintext (like with Gmail's "Strip formatting" button).

Output raw HTML when "field is not valid for Markdown rendering"

I just wanted to type a post in a forum that allows for HTML comments but only supplies a simple text field for raw HTML input; so I started writing my message in Markdown, believing that i could later convert it to HTML. However, MarkdownHere tells me that "The selected field is not valid for Markdown rendering. Please use a rich editor."

MarkdownHere should ask: "The selected field is not valid for rich text editing. Do you want convert the Markdown source to raw HTML?" and provide an "Ok"- and a "Cancel"-button along with a checkbox for "Don't ask before converting to raw HTML" (which has no effect if you cancel).

Chrome: Menu item should not show when not applicable

Firefox only shows the the "Markdown Toggle" menu item when an email-compose-like element has focus (see source).

Chrome shows the menu item for all "editable" elements. This is undesirable -- in the best case, clicking the menuitem will do nothing for most non-email-compose elements.

I have tried and failed to restrict when the menuitem is shown in Chrome. Capturing contextmenu and mousedown events is very difficult in dynamically created iframes (and if you think something is working, be sure to try all three webmail clients). I tried using a "DOM mutation observer" and couldn't get it working (and mutation events are deprecated and, apparently, evil).

Here's the branch where I was trying to get this to work.

GFM: no support for special links

Due to a limitation in the Markdown renderer that we use -- markedjs/marked#44 -- there is no support for the special GFM links (to rev hashes, issues, etc.).

However... like the Marked author, I don't actually care about this feature, and I'm not sure I want it in Markdown Here. This bug is really just a record of our deviation from the GFM spec.

(This issue is forked from #9.)

Can't see context menu in Postbox email

Hi
I'm using the Postbox email client on MacBook Air. I'm running the latest version of Mountain Lion, the lastest version of Postbox (3.0.5) and the latest Markdown Here add-in (2.5.2). I've installed MDH, restarted Mailbox several times and can't see the context menu when I "right click" (ctrl-click). I've made sure that Mailbox is properly closed in between restarts. Rich text editing (html editing) is enabled for all my email accounts.
I've just also tried disabling MDH, restarting PB and then re-enabling it and restarting. No good. And also removing and re-installing MDH... no good.
I appreciate that Mailbox isn't quite the same as Thunderbird, but with the recently announced dev freeze on TB a lot of people are now using it. It seems to work with most TB add-ins, for instance I'm using Lightning calendar with it, with no problems.
Thanks
Mark

Yahoo/Hotmail: Clicking formatting button breaks Markdown Toggle

Reproduction:

1. In Chrome (haven't confirmed Firefox) open the Yahoo mail editor.
2. Type some text.
3. Click the B (bold) button.
4. Click back into the compose area.
5. Right-click and click "Markdown Toggle".

Markdown Here's "The selected field is not valid for Markdown rendering. Please use a rich editor." will result.

The problem is that findFocusedElem() is finding the bold button instead of the compose box.

Not sure yet how to fix it. activeElement isn't an array, it's a single value, so it's not like there's a concept of more than one active element... even though the compose box clearly has focus. Maybe activeElement isn't the correct thing to use for finding the focused element?

Does each iframe have its own activeElement (that can all be meaningful at the same time)? Maybe all iframes should be traversed until a valid Markdown Here target is found?

Workaround: Click on the font size combo box and then back into the compose box. (Which makes no sense, but it works.)

This bug is especially bad since the "maintain pre-formatted text" feature was added, which encourages (or at least doesn't dissuade users) to click the formatting buttons.

Options page is broken in Firefox and Thunderbird 17

The editable fields aren't being filled in, and the preview frame isn't working. There are no errors in the JS console.

I'm not yet sure what the problem is, but I'll try to sort it out quickly.

If anyone has any insight, feel free to chime in.

"Read markdown, but send plain"-Option?

In Thunderbird, I'd like to have it this way: I send and receive plain text, but read mails markdown compiled.

What do you think?

GFM tables not supported

Due to a bug in our Markdown renderer -- markedjs/marked#50 -- we do not have support for GFM-style tables.

For example, this...

First Header | Second Header
------------ | -------------
Content Cell | Content Cell
Content Cell | Content Cell

...renders to this in Github...

First Header	Second Header
Content Cell	Content Cell
Content Cell	Content Cell

...but not in Markdown here.

(This issue is forked from #9.)

Preformatting in code blocks results in visible tags

Any preformatting (using Gmail formatting buttons, for example) done in a code block will result in the formatting tags being visible after Markdown-Toggling. This is because the <pre> block doesn't render any internal tags.

Workaround: Don't put formatting in code blocks.

It would be nice to fix this, but I can't think of a clean approach yet. Some ideas:

• Remove the keep-preformatting feature completely. It's a bit convenient, but it's mostly a crutch that maybe no one uses. If it's going to potentially cause problems, then maybe it's not worth it.
• When escaping styling tags during the HTML-to-plaintext step, don't escape tags that are in code blocks. I think that this is easier said than done -- I'm not sure how to do it reliably.
• Somehow tie the HTML-to-plaintext (jsHtmlToText) and plaintext-to-Markdown (marked) code closer together. We need to do the first step conversion before the second step, but we don't know what tags should and shouldn't be kept in the first step until we do the second step. So, do some tentative to-plaintexting, then do some from-plaintexting, and then maybe backup and change the to-plaintexting because it turned out it was being rendered to a <pre> block. Sounds horrible.

Multi-word font names in stylesheet

As the header in default.css states, multi-word font names can mess up the styling.
I think the reason is that you inline the style so that double quotes in the value of the style conflict with the double quotes used to enclose the style attribute, i.e.

<span style="font-family:"Courier New";">

A solution is using single quotes in the stylesheet.

Thunderbird: Error when rendering empty email

Reproduction: Create a new email. Put focus into compose area. Click Markdown Toggle button. Check error console.

The following will be seen:

Timestamp: 2013-02-02 10:53:46 AM
Error: InvalidNodeTypeError: The supplied node is incorrect or has an incorrect ancestor for this operation.
Source File: resource://markdown_here_common/markdown-here.js
Line: 365

At this point in time, that line corresponds to this:

markdown-here/src/common/markdown-here.js

Line 365 in 8cf8f2a

selectedRange.selectNode(rangeWrapper);

I'm marking this as low priority, since it doesn't happen once something is typed. And everything seems okay even after it happens. So there's very little actual impact besides an error console entry. (But I am afraid that it may indicate an underlying edge-case logic problem.)

Inline quoting workflow in Gmail should be easier

I often use inline quotes to reply to specific parts of mails I receive. In order to do that, I simply have to press Return to create a non-quoted paragraph below the one I reply to. In plain text, this works similarly.

However, with the markdown-here extension, quotes have to use Markdown syntax, which won't work with the typical inline quoting workflow, because:

• The rich-text quote inserted by Gmail is not valid Markdown syntax
• The plain-text quote would be, but you can't convert to Markdown when you're in plain-text mode.

I would suggest to make the conversion aware of Gmail's default rich-text quotes, so that inline quoting can be used the way Gmail offers it. I assume the situation is similar for other online rich-text editors.

Table align bug

In the example preview I found a tiny bug:

The markdown table is supposed to have the second column centered and the third column aligned right. The respective cells get a align="right" property, but they also get a style property, which effectively overwrites that:

border: 1px solid rgb(204, 204, 204); text-align: left; margin: 0px; padding: 0.5em 1em;

With text-align:left; removed from table tr th, table tr td in the "Primary Styling CSS" it works just fine.

Google Documents integration

Any chance to get this to work with Google Documents (aka Google Drive)?
I love this extension and I would really like to use it with my google docs: this would allow to easily adapt the appearance of the document elements without being constrained by google docs own styles/structure elements.
For example: there is no "code" style in google docs so the best you can do is manually select the font each time etc which is very unsatisfying.

An option would be to exploit the Google App Script framework but it does not seem to support injection of HTML+CSS into the document.

Any idea on how to do that?

TeX Math rendering

I am proposing to add TeX math rendering via Google Charts or the like.

The only change needed is in marked.tex that needs to be patched as follows

--- marked.js   2012-08-06 16:26:22.155518000 +0100
+++ marked-tex.js   2012-08-07 17:59:24.654090000 +0100
@@ -306,3 +306,3 @@
 var inline = {
-  escape: /^\\([\\`*{}\[\]()#+\-.!_>])/,
+  escape: /^\\([\\`*{}\[\]()#+\-.!_>\$])/,
   autolink: /^<([^ >]+(@|:\/)[^ >]+)>/,
@@ -312,2 +312,3 @@
   reflink: /^!?\[(inside)\]\s*\[([^\]]*)\]/,
+  math: /^\$([^ \t\n\$][^\$]*[^ \t\n\$])\$/,
   nolink: /^!?\[((?:\[[^\]]*\]|[^\[\]])*)\]/,
@@ -317,3 +318,3 @@
   br: /^ {2,}\n(?!\s*$)/,
-  text: /^[^\0]+?(?=[\\<!\[_*`]| {2,}\n|$)/
+  text: /^[^\0]+?(?=[\$\\<!\[_*`]| {2,}\n|$)/
 };
@@ -341,3 +342,4 @@
   strong: /^__(?=\S)([^\0]*?\S)__(?!_)|^\*\*(?=\S)([^\0]*?\S)\*\*(?!\*)/,
-  em: /^_(?=\S)([^\0]*?\S)_(?!_)|^\*(?=\S)([^\0]*?\S)\*(?!\*)/
+  em: /^_(?=\S)([^\0]*?\S)_(?!_)|^\*(?=\S)([^\0]*?\S)\*(?!\*)/,
+  math: noop
 };
@@ -346,3 +348,3 @@
   url: /^(https?:\/\/[^\s]+[^.,:;"')\]\s])/,
-  text: /^[^\0]+?(?=[\\<!\[_*`]|https?:\/\/| {2,}\n|$)/
+  text: /^[^\0]+?(?=[\$\\<!\[_*`]|https?:\/\/| {2,}\n|$)/
 };
@@ -369,2 +371,9 @@

+    // math
+    if (cap = inline.math.exec(src)) {
+      src = src.substring(cap[0].length);
+      out += '<img alt="'+cap[1]+'" src="https://chart.googleapis.com/chart?cht=tx&chl='+encodeURIComponent(cap[1])+'">';
+      continue;
+    }
+
     // autolink

or along the same lines.

I am aware of one big downside of this approach: the image gets rendered on the fly by google chart so your TeX formula flies around the net every time you (or the receiver) view it.
This conflicts with the general idea of Mardown-here rendering the content completely in-browser.

A fully fledged solution could present an option to disable this feature if "no info leak" is a strong requirement.

The added functionality is in my opinion a huge gain when working on scientific projects with collaborators.
A warning that this is not rendered in browser would in my opinion be enough.

Significant whitespace at the end of lines is being lost from Markdown

According to the Markdown spec, two spaces at the end of a line indicates a hard line-break (<br>) should be inserted in the rendering.

But the original-HTML-to-plaintext module we're using strips trailing whitespace. See:
https://github.com/adam-p/markdown-here/blob/master/src/common/jsHtmlToText.js#L72

Unfortunately, there are no hooks in htmlToText that will let us skip the stripping. So we'll either have to:

• modify the code directly
  • distasteful because it makes it harder to pull in any updates to the original project
• in the preprocessing hook, replace trailing whitespace with placeholder tags, and then swap them back to the original whitespace in the tagreplacement hook
  • distasteful because it's ugly

Originally discovered by a Reddit commenter.

Textarea support

Came across this and was impressed... pretty awesome.

There are a few other cases where this would be even more useful -- within standard <textarea>.

• Forums like phpBB or vBulletin that want BBCode (BBCode sucks compared to Markdown)
• Craigslist thats OK with HTML
• Other textarea based sites

So I'm not sure the best approach -- could overlay the existing textarea with a contenteditable div... or mod the DOM to add the attribute to the textarea -- which probably has side effects.

Just thought I'd throw it out there -- this would increase the utility of this extension quite a bit IMHO.

Thanks for the consideration!

Warn before losing content when reverting

From the description:

Note that any changes you make to the pretty HTML will be lost when you revert to Markdown.

I do understand, that it would not be easy (although awsome) to keep the edits to the HTML also in Markdown (e.g. that <b>blah</b> would get **blah**), but i think, that

• one should be warned, when toggling from HTML to Markdown
  • if the content differs from Markdown Here-output

That is if someone is just switching back and forth to see the difference, or to check the output, there should be no warning.

Yahoo losing paragraph spacing on send and receive

Yahoo is losing paragraph spacing when it sends email and when it receives email from other webmail clients. The result can be seen in both browsers (and all receiving webmail clients).

This may be related to #2, but is probably not identical.

Chrome: Make button a page action

#34 added a button to the Chrome toolbar. That button is often disabled, because we're not in a rich-text field it can operate on. Chrome has an even better system for this called Page Actions.

http://developer.chrome.com/extensions/pageAction.html

A Page Action is like a Browser Action (the current type of button), but it only shows up conditionally, and it appears inside the URL bar. You can use chrome.pageAction.show() and chrome.pageAction.hide() to show and hide it as applicable.

This way, the button gets out of the way when it's not useful, and appears when it can help.

Better indication of modified-ness of themes

To quote a user:

On the Options page, it would be great if the Theme, if unaltered, would say what theme was selected, instead of "Currently in use".
Going even farther, if I start with Solarized Light and then make some changes, I would love for the Theme to say "Custom theme based on Solarized Light".

No Keyboard Shortcut to Toggle Markdown

Can you add a user-definable keyboard shortcut? Thanks!

Gmail plain text mode is not detected

Some time in the last six months Gmail changed it's plaintext mode from using something like a textarea to using the same contenteditable element that it uses for rich edit mode (and it switches seamlessly to rich mode if the user formats the text).

So now, if Gmail is in plain text mode Markdown Here will not notice. It will render the email without complaint, it will put the rendered content into the email body, and the email will be sent without apparent problem. But the recipient will get only the plain text version of the email.

This is fairly severe. There's no indication of what the problem is, and it will be very disappointing to users to find that their MDH efforts have been wasted. (I've had one user who encountered this behaviour and, quite reasonably, thought that MDH was broken.)

I'm not sure what the fix is yet. I hope there's an attribute or style that can be checked (which means an unpleasant special-case check, but... maybe no choice).

Converting a selection can result in a proliferation of emtpy `<div>`s

Reproduction:

1. Create an email with a few lines separated by empty lines.

2. Inspect the DOM. It should look like this:

   <div>my line 1</div>
   <div><br></div>
   <div>my line 2</div>
   <div><br></div> 

3. Select a line but putting the cursor at the beginning of a non-empty line, holding the shift key, and pressing the down key.

4. Markdown Toggle.

5. Look at the markdown-here-wrapper that was created -- its data-md-original attribute has an empty <div> at the end of it that wasn't present in the original DOM.

If you then revert and repeat, there will be two empty <div>s, and so on.

The problem is that the range of the original selection has an endContainer of the <div><br></div> (outer) element, and a endOffset of 0, which means that it ends before the <br>.

Then in getSelectedHtml(), when we call selectedRange.cloneContents(), the partial <div> turns into an empty <div> element, and the original stays on the page (or it might be a new one enclosing the original <br> -- same result).

Impact

It's hard to know how severe this bug is. If it's just creating empty <div>s, then it's pretty minor. But, in theory, it could introduce more significant elements.

Even with <div>s, it can still mess up the Markdown. For example, if you have two plaintext lines with no empty line between then, they will be treated as the same line when rendering. But if you convert and revert the first line, then there'll be an empty <div> between then. If you then try to convert both lines, they'll be rendered as two separate lines. It's not difficult to recover from the situation, but it could be confusing and annoying.

Solutions

A simple solution might be to remove empty <div>s at the end of the output of getSelectedHtml(). But this doesn't account for the possibility that this bug can affect other tag types.

Maybe there will always be an empty element at the end of the outerHTML when the endOffset is 0? If so, that might be a good general solution.

A more robust solution might be to shrink or grow the end of the range so there's no partial element. But I'm not sure that this will actually work. And ranges are still a bit mysterious to me. And I fear the potential for bad side-effects.

Retain pre-formatted links

This feature did once exist, but I removed it (5f1840b) for this reason:

Removed feature: Pre-formatted links are no longer left intact. It conflicted with Marked.js's GFM behaviour of turning text that looks like a URL into a link. So if a pre-formatted link was created that used the URL as the text (e.g. http://github.com), the resulting rendering would get messed up (<a ...><a ...>...). Let this be a lesson about the perils of frivolous features.

However, I think it's an important feature because not having it means data loss -- the link destination. I've had one report already of exactly that -- the user didn't notice he'd lost a link.

This time, instead of escaping the link so that it ends up in the output, I think a better approach is to convert the link to Markdown before rendering.

Render recieved messages

What I'd like to see is a plugin, that renders plain text messages into markdown. This way one could send plain text markdown coded messages to each other. Those who have the plugin would see the rendered code and those who don't would see the markdown code which still is very easy and convenient to read.

For many html emails are not an option. PGP encryption/signing etc. That's why this kind of plugin would be great!

Looking forward for this kind of fork of the project!

Provide a Button

Using the shortcut for toggling is good, but some (including me) might prefer to have a button for toggling.

The button should ideally be greyed out when no text-field is selected.

Markdown toggle doesnt work in Thunderbird

Markdown toggle doesnt work in Thunderbird under Ubuntu OS
My English is not good, hope you can understand :)

GFM-style line breaks not supported

Due to a bug in the Markdown renderer we use -- markedjs/marked#51 -- GFM-style line breaks are not supported.

So, in Github, this Markdown will render to two lines, but in Markdown Here it'll be one line:

line the first
line the second

(This bug is forked from #9.)

Do not render signature text as md

Hi. Nice tool! I am very much enjoying it, with one minor hickup. In my email body gmail already generates a signature (one that starts with "-- \n" at the beginning of the line, after which the signature follows. Toggling markdown-here will also render this signature. Could you add an option to disable the rendering of the text after "-- \n" in the body? Thanks!

Hotmail losing paragraph spacing on send

Hotmail is losing paragraph spacing when it sends email. The result can be seen in all receiving webmail clients in both browsers.

Does not work in Gmail's New Compose window

Gmail has a new "Compose" feature that is currently still in Beta.

While it supports the normal rich text markup and also responds to shortcuts such as ⌘B etc., MDH doesn't appear to work in this field. Clicking the button does nothing—same for the Markdown Toggle! from the context menu.

I'm using Chrome 26.0.1403.0 (dev) and MDH 2.7.0.

Would it be possible to add this?

_{By the way, MDH has changed my (e-mail) life. Thank you so much for this extension.}

Thunderbird: img tags lose correct src

<img> tags in Markdown look good when rendered, but when they get sent, the src attribute changes something like "cid:[email protected]". This results in broken images for all receivers (even the sending Thunderbird client).

CSS being applied to excluded reply text

Reproduction (easiest to do in Chrome):

1. Use Gmail or Thunderbird, since only they have properly excluded replies.
2. Send a rendered email to yourself. (Put a code block in it, to see the problem easily later.)
3. Change the Markdown Here CSS that will affect the contents of the original email. (Pick a new syntax highlighting theme.)
4. Start a reply to that email. Type a bit of Markdown.
5. Render the email (the whole thing -- no selection).

Result: You'll see the new CSS change the appearance of the original (quoted) email.

This isn't a horrible bug, since it doesn't change the content of the quoted reply.

Plain text highlighting & multi-part support

I prefer to compose and view messages a plain text, and I know that many of my recipients do too. I'd like it if Markdown Here could send multi-part messages: a plain-text part containing the markdown source, and an HTML part with the rendered output. Further support for "plain-text" users could be provided by syntax-highlighting markdown when composing and viewing plain-text.

Chrome: Tabs in code blocks result in visible <span> tags

Reproduction: In Chrome, paste a tab into code block. Markdown Toggle. You'll see a <span> tag.

This problem is due to issue #17, but I think it's higher priority and deserves a targeted (and simpler) fix, so I'm creating a separate issue.

When a tab is pasted into Chrome, the following HTML results:

<span class="Apple-tab-span" style="white-space:pre">   </span>

With the keep-preformatting feature, when extracting plaintext from HTML we escape <span> tags with styling info (see code). So we escape the above Apple-tab-span tag. But because of issue #17, if that tab is in a code block, then the <span> tag will be visible after Markdown-Toggling.

Unlike issue #17, I think this is high priority. There are often tabs in code, and they aren't very visible to the naked eye, and it won't be clear to users why they end up with these strange <span> tags in their code.

The obvious fix is to target these tags directly. I'm a little afraid that there are many other such tags that I don't know about (I found this one by accident), but some Googling hasn't shown any others (there's also a <span class="Apple-converted-space">, but it doesn't have a style attribute, so it won't be escaped). I think that I'll target the fix to this tag and deal with the more general problem if more instances arise.

So PLEASE open a bug if you find anything else like this.

Interesting reading about a related tag: http://www.webkit.org/blog/1737/apple-style-span-is-gone/

doesnt work when used with Google Apps Gmail

I'm trying to use it with my google Apps account gmail

i can see the "markdown toggle" context menu command but it does completely nothing.

i tried to login to normal gmail.com account, and it worked, so I guess the problem is not related to my environment (newest chrome)

Firefox extension not available anymore

The link on the project page / README.md gives me a Not Found page. And searching markdown in Firefox Add-on center does not show Markdown Here among the results.

Firefox: Ensure text not selected after rendering

In Firefox (and maybe Thunderbird?), after Markdown Toggling the rendered text ends up selected. This is inconsistent with the way Chrome works, and the selection makes it difficult to see the formatting and colour of the rendered content. The selection should be cleared after rendering.

(Make sure to end up with the cursor in a sane place.)

Update unmodified CSS if default changes

If the default "Primary Styling CSS" or the user's currently selected "Syntax Highlighting CSS" changes in a release, and the user hasn't modified the previous default, then the user's styles should update to the new default.

Alternatively, the user could be prompted. Perhaps they prefer the previous default -- even though the new one should be better (by some measure) or it wouldn't have been changed.

I guess the ideal would be to save the previously set CSS as an easily selectable value, in case the user wants to revert, and set the new default as the current. (An even-more-fanciful ideal might be to diff/merge the new and the user's current, and only replace those rules that haven't been modified. That's getting pretty tricky/dangerous, though.)

For new users, this could be mitigated by not immediately writing the default as the user's setting. Then it would only get set if they modified it.

This problem is especially heinous right now because a default CSS change in 2.7.0 was needed for the new Markdown table column alignment to work. But users have to manually reset their CSS or else it appears broken. For example: #47