Re: The less ambiguous math delimiters in tables

On 03/01/2025 00:32, Ihor Radchenko wrote: Max Nikulin writes: On 31/12/2024 20:32, Ihor Radchenko wrote: | $10 | foo | $\alpha$ | pandoc result matches my expectation: \$10 & foo & \(\alpha\) \\ How so? I just tried Sorry, I failed to express that the above example is handled perfectly

Re: The less ambiguous math delimiters in tables

Max Nikulin writes: > On 31/12/2024 20:32, Ihor Radchenko wrote: >> | $10 | foo | $\alpha$ | > > pandoc result matches my expectation: > > \$10 & foo & \(\alpha\) \\ How so? I just tried printf '%s\n' '| =10+20 | 30 | =foo= |' | pandoc -f org -t latex \begin{longtable}[]{@{}l@{}} \toprule\noali

Re: The less ambiguous math delimiters in tables

On 31/12/2024 20:32, Ihor Radchenko wrote: | $10 | foo | $\alpha$ | pandoc result matches my expectation: \$10 & foo & \(\alpha\) \\ | =10+20 | 30 | =foo= | I found significantly more convincing cases with current parser when emphasis end marker accidentally appears in the middle of a lin

Re: The less ambiguous math delimiters in tables

On 31/12/2024 04:25, Rudolf Adamkovič wrote: Max Nikulin writes: An extensive test suite is necessary to consider alternatives for parsing rules. Yes, that much is given. Without an extensive test suite, working on a parser would be nothing but a waste of time, and the end result would be, at

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: >> It is not just about \(...\). > > Of course, and I agree that a more general mechanism is needed to solve > all precedence problems, be it in tables, or (better) in general. But, > as I said before, even if we had such a mechanism, it should not be > necessary to use

Re: The less ambiguous math delimiters in tables

Ihor Radchenko writes: > It is not just about \(...\). Of course, and I agree that a more general mechanism is needed to solve all precedence problems, be it in tables, or (better) in general. But, as I said before, even if we had such a mechanism, it should not be necessary to use it for \(...

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: >> ... | \(first cell | mid | last\) | > > But how many Org tables exist in the world that have a row with an > un-closed \( in one cell and an un-closed \) in a subsequent cell? It is not just about \(...\). Consider other verbatim Org markup like | $10 | foo | $\alpha

Re: The less ambiguous math delimiters in tables

Ihor Radchenko writes: > These edge cases come in pairs: > > printf '%s\n' '| \(first cell | mid | last\) |' | pandoc -f org -t latex > \begin{longtable}[]{@{}l@{}} > \toprule\noalign{} > \endhead > \bottomrule\noalign{} > \endlastfoot > \(first cell | mid | last\) \\ > \end{longtable} But how m

Re: The less ambiguous math delimiters in tables

Max Nikulin writes: > 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 chan

Re: The less ambiguous math delimiters in tables

Max Nikulin writes: > 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 exp

Re: The less ambiguous math delimiters in tables

Ihor Radchenko writes: > FYI, my approach to solve this problem is different - I want > (eventually) to allow some kind of alternative syntax for tables that > will allow bypassing similar situations. For example, we can allow > multiple || to serve as delimiters: > > | this | is | a | no

Re: The less ambiguous math delimiters in tables

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.

Re: The less ambiguous math delimiters in tables

On Wed, Dec 25 2024, Rudolf Adamkovič wrote: > Ihor Radchenko writes: > >> It is a syntax limitation. >> Org parser is outer-inner - the table row is parsed first. >> So, | are unconditionally used as table delimiters, *before* verbatim >> LaTeX markup is recognized. > > How is that not a parser

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: >> In a theoretical case if we agree to what you are suggesting, it should >> not be just for tables. There are similar cases with other markup, like >> >> *foo =* *= bar* > > Agreed! We could introduce a kind of escaping that means "this MUST be > interpreted as markup

Re: The less ambiguous math delimiters in tables

Ihor Radchenko writes: > In a theoretical case if we agree to what you are suggesting, it should > not be just for tables. There are similar cases with other markup, like > > *foo =* *= bar* Agreed! We could introduce a kind of escaping that means "this MUST be interpreted as markup" and/or "t

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: >> Maybe, but it is also much more complex in terms of parser. >> Backtracking will introduce non-linear complexity to the parser, >> degrading the performance significantly. > > Is that so? I thought it is all about simple precedence rules. In this > case, once the par

Re: The less ambiguous math delimiters in tables

Ihor Radchenko writes: > Maybe, but it is also much more complex in terms of parser. > Backtracking will introduce non-linear complexity to the parser, > degrading the performance significantly. Is that so? I thought it is all about simple precedence rules. In this case, once the parser finds

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: >> 1. \(x\) >> 2. |x| >> >> Org parser chooses one. It has to choose some. >> Org parser also chooses a simpler interpretation that does not require >> backtracking. > > But (2) is a *much, much, much* better choice (for the user). Maybe, but it is also much more com

Re: The less ambiguous math delimiters in tables

Ihor Radchenko writes: > Your example shows ambiguous markup that can be > interpreted in multiple ways: > > 1. \(x\) > 2. |x| > > Org parser chooses one. It has to choose some. > Org parser also chooses a simpler interpretation that does not require > backtracking. But (2) is a *much, much,

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: >> It is a syntax limitation. >> Org parser is outer-inner - the table row is parsed first. >> So, | are unconditionally used as table delimiters, *before* verbatim >> LaTeX markup is recognized. > > How is that not a parser bug? > > I thought that, with the noisy \(...\)

Re: The less ambiguous math delimiters in tables

Ihor Radchenko writes: > It is a syntax limitation. > Org parser is outer-inner - the table row is parsed first. > So, | are unconditionally used as table delimiters, *before* verbatim > LaTeX markup is recognized. How is that not a parser bug? I thought that, with the noisy \(...\) delimiters,

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: > P.S. I know about '\vert' in LaTeX. But, I was not able to figure out how to put \(\|\vec{u}\|\) into a table. [The \| sequence typesets as || but with different spacing than \vert\vert.] Rudy -- "Logic is a science of the necessary laws of thought, without whic

Re: The less ambiguous math delimiters in tables

Rudolf Adamkovič writes: > Org still struggles with | within \(...\) in tables, > > such as > > | \(|x|\) | > > Is this a feature or a bug? It is a syntax limitation. Org parser is outer-inner - the table row is parsed first. So, | are unconditionally used as table delimiters, *before* verbat