You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
<pre>
block. Sounds horrible.The text was updated successfully, but these errors were encountered: