For too long support for Tex(tool for writing mathematical expressions) has been ignored from majority of documenting platforms. But not anymore. More and more Markdown renderers are adopting Tex interpolation; for one, Dev.to just started supporting Tex(via KaTex) only couple month ago (This is the biggest reason I moved from Wordpress and Medium). But still there are a lot of things remaining to be improved and one of which is the fact that unfortunately, using $
($$
for display mode) as delimiter became a convention.
I'm glad that Dev.to didn't(or rather had to for using Liquid) follow the convention because $
makes a terrible delimiter for Tex in Markdown. Whether you are a developer of a Markdown renderer or a user who writes and manages lots of documents written in the format, you need to be able to accurately match Tex blocks. And I’m telling you, $
as delimiter makes it absolutely hideous. Here's why $
makes terrible delimiter for Tex in Markdown:
Tex itself uses $
as delimiter for nested Tex
Imagine you are writing this:
If you were using $
as delimiter, the Tex code would have been:
$\text{In quaternion $i^2$, $j^2$, $k^2$, $ijk$ and $-1$ are all equal.}$
\text
macro has 5 nested Texs and they are all delimited by $
. How are we supposed to match it? By using regex? Let’s see. Obviously you can’t just capture anything inbetween $
s like $(.+?)$
, you can’t use greedy matching because one line can contain multiple Texs. You will eventually have to rule out explicitly every macro commands that can contain nested Tex, for there are several.
$
is used frequently in programming languages
Even if you had managed to write a regex pattern that matches Tex code delimited by $
in account of previous problem, you will only face another problem. Imagine following text is written in a Markdown:
This haskell code, `let r = g $ f (x) $ y `, is legitimate!
This inline Tex code, $ f (x) $ is legitimate as well!
Where the expected output is this:
This haskell code, let r = g $ f (x) $ y
, is legitimate!
This inline Tex code,
is legitimate as well!
Former $ f (x) $
shouldn’t match because it’s a syntax of a programming language. How can we match only the latter one? Ignore everything in block elements? That’s just irresponsible compromise of functionality. Someone would want to use Tex in block elements. At this point pattern matching became practically impossible and you would start considering parsing the entire Markdown to know which block element is code block.
Haskell is not the only one who uses $
a lot. Every jQuery statements starts with $
. PHP uses it to refer a variable. Shellscript uses it to refer arguments. Ruby, Groovy, C#... lists goes on and on. One of the reason I had to make a Markdown renderer for myself was that the renderer kept changing small portion of my code into Tex! Do you know how annoying that is?! Imagine you had to spot changes from this:
let third x = head $ tail $ tail x
to this:
let third x = head tail tail x
in the middle of hundres of codes!!!!!!!!!!!
$
is also frequently used in daily writings
$
is used all the time in daily writing e.g. name of the artists, currencies, meta usage like this article... you can easily imagine how hard distinguishing Tex blocks among them would be.
How did it happen?
Yet most of the markdown renderers with Tex support uses $
as delimiter. But Why? Why and how did it became a convention?
It's because MathJax and Katex, the two mostly used library for displaying math expressions, uses $
as default delimiter to dynamically find Tex(or MathML) codes in html pages and inject displaying elements. Of course there’s no way that such global search & replace tactic on entire html page will work smoothly. Yet it exists because it's very convenient.
What to use as delimiter?
I like GitLab's way of supporting math in Markdown.
Top comments (0)