AsciiMath and conj

[jolyonb]

When in the process of typing a formula, conj and conj( return math processing errors from asciimath. We should probably figure out what's going on here and just render as conj and conj( respectively.

[ChristopherChudzicki]

OK, so I looked into this a bit tonight.

The edX version of AsciiMath seems to show "Math Processing Error" when symbols that AsciiMath classifies as mover and mtext are wrapped in nonbreaking blocks. For example:

• mover: {:overline:}, {:overbrace} Math Processing Error, but overline, overbrace display fine fine
• mtext: {:text:} Math Processing Error, but text displays fine
• {:sin:}, sin both display fine, as do all our normal functions and symbols (they use mo and mi)

You can test this in a <textline math='1' /> field. It has nothing to do with our library. Note that the AsciiMath website has no trouble displaying {:overline:}. I'm not sure if they do some extra processing, or if this is a bug that was fixed.

This issue comes up because preProcessEqn wraps function calls and symbol names in non-breaking blocks. For example:

 // Display fine:
 preProcessEqn('conj(z)') // {:conj({:z:}):}
 preProcessEqn('conj()') // {:conj():}
 // Math Processing Error
 preProcessEqn('conj') // {:conj:}
 preProcessEqn('conj(') // {:conj:}(

Incidentally, that means only problems using our preprocessor suffer this issue. Some problems in our demo course only use the extra symbols, and they work fine.

A Fix: I'm not sure of a good way to fix this issue. I'll submit a PR (#164 ) with a hacky method, and you can decide whether to merge it.

[jolyonb]

Resolved well-enough by #164. The issue seems to be in the MathJax implementation of AsciiMath, and I don't want to go there. The hack avoids the issue for conj, which is the only mover symbol that we define. If it becomes an issue later on, we can revisit this, but I suspect it won't.