Re: Inequalities in math blocks

[Max Nikulin]

On 12/10/2021 08:11, Nick Dokos wrote:
> Rudolf Adamkovič writes:
> > Max Nikulin writes:
> >
> > > Though I am a bit surprised that Org did not replace characters to
> > > <  and > during export. Perhaps, it is possible to define a
> > > filter.
> >
> > That makes sense, and thank you for the explanation. Ignoring the dead
> > link in the Org manual, I wonder how this bug can even exist in Org
> > after 15+ years of development. Some people, including the author of
> > TeX himself, write TeX without unnecessary whitespace. Strange! Either
> > way, rearranging bullet points should never break math without any
> > visual sign inside of Emacs. Thus, this represents a bug in Org. R+
>
> No, it does not. Org mode just passes LaTeX directly to MathJax
> without changing anything. If you want to blame somebody, you can
> blame HTML for choosing < and > as its delimiters: see
>
>     
> http://docs.mathjax.org/en/latest/input/tex/html.html#html-special-characters

Nick, I am sorry, but I do not see your point. Do you know any reason 
why Org properly escapes "<>&" in text but transparently passes them to 
HTML inside LaTeX fragment? Does escaping them everywhere lead to problems?

From the referenced document (I posted this link on 2021-10-03):

> you need to be careful that your mathematics doesn’t look like HTML tags
> to the browser, which parses the page before MathJax gets to see it.
...
> you can use the HTML entities &lt;, &gt; and &amp; to encode these
> characters so that the browser will not interpret them, but MathJax will.

I fail to see any reason to blame HTML. Any text markup language 
requires some easily typed special characters. Org has one set of them, 
HTML another one. Export backend should just respect delimeters of the 
target format.

I understand expectations and thus complains of Rudolf. In my opinion he 
has reasons to be disappointed (and maybe even angry to some degree). It 
looks like a bug in Org that should be fixed. Workarounds exist but Org 
should be more reliable.