On 26/12/2024 00:56, Rudolf Adamkovič wrote:
I thought that, with the noisy \(...\) delimiters,
GitHub users faced ambiguities with $...$ delimiters as well, so do not
be upset by "noisy" syntax. Alternatives may be painful as well.
<https://nschloe.github.io/2022/06/27/math-on-github-follow-up.html#-vs-dollar-bugs>
I have no idea how expensive will be a parser that handles more cases
with balanced delimiters. E.g. pandoc uses another approach:
printf '%s\n' '| \(|x|\) | \(|x|\) |' | pandoc -f org -t latex
\begin{longtable}[]{@{}ll@{}}
\toprule
\endhead
\(|x|\) & \(|x|\) \\
\bottomrule
\end{longtable}
Likely you would be unhappy if some of you document were exported in a
different way due to change of parsing rules. On the other hand, I do
not have a collection of pitfalls for pandoc.
An extensive test suite is necessary to consider alternatives for
parsing rules.
Current logic may be roughly describes as the following. When Org
recognizes start of some element, it tries to find its end, mostly
neglecting opening markers. A fragment is parsed for nested elements
*after* boundaries of the parent element are determined.
The parser ignores latex fragments when it splits table row into cells.
It ignores link markers when it tries to find where emphasis terminates,
etc.
