Having the MO Mathjax parser recognise \( \) is a regex away

Question

@IsabelBeckenbach discovered why \( \) isn't accepted as a math-mode delimiter on MO. I'd always thought it was a design choice, but apparently it's just a mis-escaped regex. I suggested that they promote their discovery to a bug report, and am only doing it myself because they do not seem to prefer to do so; but all credit for the discovery is theirs, and the following is quoted literatim:

---

I think the problem has something to do with the MathJax Configuration at mathoverflow:

<script type="text/x-mathjax-config">
                MathJax.Hub.Config({"HTML-CSS": { preferredFont: "TeX", availableFonts: ["STIX","TeX"], linebreaks: { automatic:true }, EqnChunk: (MathJax.Hub.Browser.isMobile ? 10 : 50) },
                    tex2jax: { inlineMath: [ ["$", "$"], ["\\\\(","\\\\)"] ], displayMath: [ ["$$","$$"], ["\\[", "\\]"] ], processEscapes: true, ignoreClass: "tex2jax_ignore|dno" },
                    TeX: {
                        extensions: ["begingroup.js"],
                        noUndefined: { attributes: { mathcolor: "red", mathbackground: "#FFEEEE", mathsize: "90%" } },
                        Macros: { href: "{}" }
                    },
                    messageStyle: "none",
                    styles: { ".MathJax_Display, .MathJax_Preview, .MathJax_Preview > *": { "background": "inherit" } },
                    SEEditor: "mathjaxEditing"
            });

In particular the deliminators for inline math are defined to be

[ ["$", "$"], ["\\\\(","\\\\)"]

E.g. when using

\\\\(L^ 1 \cap L^ \infty [0, \infty )\\\\)

one gets the correct mathjax rendering

\\(L^ 1 \cap L^ \infty [0, \infty )\\)

So, one should replace

[ ["$", "$"], ["\\\\(","\\\\)"] ]

by

[ ["$", "$"], ["\\(","\\)"] ]

Answer 1

The real issue with using \(...\) as math delimiters is the interaction with StackExchange's Markdown engine, since Markdown uses \ as an escape character to prevent the next character from having its usual Markdown function. That is, you can use \*abc\* to get *abc* without the asterisks having their usual property of italicizing the letters between them.

Because of this, when you enter \( Markdown converts that to just ( in the HTML page, and so this would mean that MathJax (which runs in the browser, well after Markdown has removed the backslashes) only sees regular parentheses, not \( and \). In order to get \(... \) into the HTML output where MathJax can pick it up, you would need to enter \\(...\\) in the editor, so that Markdown would turn \\ into \ and send \(...\) to the browser.

Note, however, that the configuration uses javascript strings, and javascript strings use backslashes as escape characters as well. So in order to specify \( and \) as delimiters, you need to use ["\\(", "\\)"] in the inlineMath delimiter array. (That is not a regular expression, just a string, and MathJax takes care of turning it into a regular expression and handling regular-expression special characters.)

It looks like someone has mistaken the fact that you need to type \\(...\\) in Markdown to think that the configuration should be ["\\\\(", "\\\\)"], which makes the delimiters be \\( and \\) in the HTML page, forgetting that when you type \\(...\\) in Markdown, what ends up in the page is \(...\) instead. That would mean you would have to type \\\\(...\\\\) in the editor in order to get \\(...\\) into the HTML resulting HTML page, in order to have the right delimiters for this configuration.

So you (and @IsabelBeckenbach) are right that the configuration is incorrect, but you have the wrong reason. It's not about regular expressions, it is about the Markdown processing that happens to the text you enter before it goes to the browser where MathJax sees it.

The displayMath configuration that uses ["\\[", "\\]"] does mean that the delimiters are \[...\] and so you can get this in Markdown by typing \\[...\\] in the editor.

Still, all of these are harder (and less intuitive since you have to deal with Markdown escaping) than $...$ and $$...$$. It would still be nice if StackExchange did fix the incorrect configuration, however, for those who prefer to use the escaped backslash delimiters. But I think the back-end (after a post is made) does additional processing, and marks the math with some wrapper tags. I suspect they only look for the dollar-sign delimiters, and may not find the backslash ones.