 attached noprotectedinmathmode.patch
At the moment, if rich text contains a {} in math mode it will also get the protected treatment (e.g. for HTML a <span>
will be inserted, for plaintext it will be removed).
This is not quite the desired behaviour though: in HTML one will probably use MathJax for the rendering, and then missing brackets is a problem.
A possible solution would be to just ignore math mode when parsing a string. More ideally one could implement a new rich text class, and e.g. use asciiMath or some humanreadable format when outputting to plaintext.
I'll have a go at the first solution one of these days.
Comments (4)

reporter 
I agree this has caused some issues for me. We shouldn't protect texts in math.
Since you are using MathJax, I think it is essential to handle
\(
and\)
rather than$
, since MathJax discourages the use of using$
as the delimiter. 
Can you perhaps make this as a PR? Since you already have the patch written up, a PR, which often significantly increase the visibility of this issue for the author(s), would be very helpful.

This latexcodec issue may also be relevant: https://github.com/mcmtroffaes/latexcodec/issues/38
 Log in to comment
Attached is the quickest solution to this problem. Some obvious issues are: no dealing with
\$
, no dealing with\(
and\)
as means to a math mode, no explicit check on math mode being closed at the end of the string.For the somewhat nontrivial use case I have in mind this solution is good enough.