Warn before losing content when reverting about markdown-here

[adam-p]

Yes, this needs to be addressed. You can see some of my older ideas in the README here: https://github.com/adam-p/markdown-here#next-steps

Your suggestion for a warning is good. It should be doable and fairly simple. I'll look into this in the not-too-distant future.

[adam-p]

I'm moving these notes from the README to here, since an issue is a better place for them.

Note that I don't think (anymore) that making the rendered output read-only is a good idea.

---

• Figure out how to prevent users from losing modifications to the rendered version when they revert.
  • Prompted by this Reddit comment.
  • Maybe add an option to make rendered mode read-only. If a user edits the rendered text and then reverts, they lose their changes, which is pretty bad. Better to not let the user make changes at all (optionally).
    • Is it possible to do that? In Thunderbird as well?
  • Maybe convert the HTML back to Markdown. (Like, actually convert it -- don't just use the stashed original Markdown.)
    • to-markdown or reMarked.js will probably be useful.

[anstosa]

@adam-p, I've recently discovered and forked Markdown Here and immediately noted the need for HTML to Markdown conversion (although the extension is otherwise fantastic!).

I will be putting some effort into this in the coming weeks, hope to shoot you a pull request or two soon!

[adam-p]

That would be awesome. (And you would have the honour of being my first ever pull request!)

[adam-p]

I should mention... Markdown Here deviates from standard Markdown in some ways. For example:

• Pre-rendered images are left intact
• Pre-rendered links are left intact
• Pre-existing blockquotes are left alone
• TeX support. ($\Delta$)

I've also been thinking about not using <p> elements in the rendered output, and instead replacing them with something like double <br>. I find that replying inline to a Markdown Here-rendered email is a little wonky, and I suspect that it's the use of <p> tags, which aren't normal for email. ...I've only been "thinking about", though -- haven't written anything.

So... that's some added complexity. Maybe there are creative ways around this, but it's quite tricky at first glance. There might need to be some case-by-case behaviour. For example:

• Pre-rendered images: a class or attribute could be added to the <img> tag to indicate that it was originally pre-rendered and should not be decomposed to MD.
• Pre-rendered links: Just decompose to MD regardless.
• Pre-existing blockquotes: They already get wrapped in <div class="markdown-here-exclude">, so use that. Or use an attribute like the <img> suggestion.

Anyway, feel free to muse and discuss, either here, or in a new issue, or in the MDH Google Group, or create a new wiki page.

[jdhines]

Along these same lines, I found that in Chrome I would lose all content entered after having toggled markdown. So if I entered something, toggled the markdown styles on, entered some more text, then toggled it back off to apply markdown, I lost everything I just added.

Also, if I delete any content, then turn off the markdown styles, the content reappears. So it looks like only in markdown mode can you create content. Am I doing something wrong?

[adam-p]

Generally speaking: When reverting from HTML back to MD, you will lose changes in the entire scope that was originally rendered. So if you rendered the entire email (which it sounds like you did, then, when reverting, you will lose changes made in the entire email when reverting. If instead you selection-render a portion of your email, only changes to that portion will be lost when reverting.

So... you're not doing anything wrong. For now, that's how it works.

[Catincan]

Bounty of $50.00 is available on this issue: https://www.catincan.com/bounty/https-github-com-adam-p-markdown-here-issues-33

[adam-p]

Added confirmation prompt when user attempt to unrender modified content (which means the changes would be lost). Rev 1a022d6

This does not work in Safari 6 (dunno about higher versions), as it does not support MutationObserver. EDIT: Safari 6 supports the prefixed WebKitMutationObserver, so it will work. Safari 5 won't, though.

The change I made just uses confirm, so it's not real pretty. Good enough for now, though.

I'm going to create another issue for converting back from the modified HTML to MD. #127

[adam-p]

Postbox 3.0.8 also does not support MutationObserver and therefore does not benefit from this change.

Edit: I created a new issue #129 for Postbox support.