Suggestion: Warn users when sending a Markdown formatted message without applying the formatter

[ppetr]

Sometimes it happens to me that I write a nicely formatted Markdown message and forget to transform it at the end. Would it be possible to add a hook to sending messages, check if it "seems" to be Markdown and ask the user for confirmation? Similarly to what email clients do with attachments - they warn the user if an email contains "attach" or "attachment", but no attached file.

The question is how to detect Markdown. Perhaps look for some often occurring patterns like "`", "word" etc.

[adam-p]

This would be great. I accidentally send without rendering all the time as well.

I think that there are two aspects to doing this, one of which is tricky and interesting, and the other is super craptastic:

1. Detect when a message is raw Markdown. Without too many false negatives or almost any false positives (no one will tolerate having non-MD email be interrupted very often).
2. Detect when the email is being sent and interrupt the sending of it. Ugh. Doing this for Thunderbird is surely straightforward. Doing it for webmail is going to mean reverse-engineering and hacking and then breaking when the site's code changes. First of all, let's not even pretend that it'll get done for all of Gmail, Yahoo, and Hotmail -- let's just say Gmail. (And never mind Evernote, Wordpress, Blogger, ...) Maybe we can handle that? (I have already tried and failed to reverse-engineer Gmail JS for issue Gmail plain text mode is not detected #50, but maybe this will be easier.)

(As I was saying in another issue's comment last night, it's becoming clearer that per-site code, styling, etc. is needed. This is seems to be another case for that.)

[adam-p]

Work on this is in progress in the forgot-to-render-detection branch.

So far it's basically working for Gmail in Chrome and Firefox. Still to do:

• Test cases for the new Utils and CommonLogic helpers.
• Some refactoring to use the request handling code in Firefox.
• A new option for disabling the forgot-to-render detection (there are surely some cases I'm not thinking of that will piss off some users by interrupting their email sending).
• A new (hidden?) option for what the character limit should be when checking if email content is MD.
• Implement for Thunderbird.
• Maybe Safari.
• Teeeeeesssssssttttt

[adam-p]

Update...

Still to do:

• Think about whether there should be more or fewer or better tests for determining whether the user is likely writing Markdown. Any help or suggestions would be appreciated. Code is here.
• Maybe Safari.
• Some refactoring to get the two openDialog calls down to one. (Maybe.)
• Add tests for CommonLogic.probablyWritingMarkdown.
• Teeeeeesssssssttttt

[adam-p]

Merged forgot-to-render branch into development. Will be in the next release.

Here's the CHANGES.md entry:

• New feature: Forgot-to-render detection. Have you ever forgotten to make your Markdown pretty before sending your email? Me too. Now Markdown Here will detect when your email contains raw Markdown and will give you second chance to go back and render it before sending.
  • This feature is supported in Thunderbird (and Postbox), and for Gmail in Chrome, Firefox, Opera, and Safari. (If anyone really cares about Hotmail, Rocketmail, etc., please chime in.)
  • For now this feature is off by default because I'm nervous about too many false positives driving people crazy. But please opt in! The checkbox to enable it is at the bottom of the MDH Options page. And please give feedback on how the feature does or doesn't work for you, either in the Github issue or the MDH Google Group.
  • Thanks to Petr Pudlák for requesting this in issue #90, Zhou Qiang in issue #96, Adam Backstrom in issue #98.

[ppetr]

Thank you very much.

[adam-p]

Due to a bug in Firefox, hitting Space to trigger the Gmail send button will scroll the message list down a page. I believe that this is due to this Mozilla bug and is fixed in Firefox 25 (I've tested in Aurora 26):
https://bugzilla.mozilla.org/show_bug.cgi?id=501496

Probably I could "fix" this by capturing the keypress event. But I don't want to add unnecessary code to work around a browser bug that will be fixed in the near-ish future. (And the workarounds pretty obvious and not heinous.)