Improve math parsing

[xxchan]

current situation

types:

• rendered in display mode: Latex_Environment & Displayed_Math
• rendered in inline mode: Latex_Fragment Inline/Display

syntax:

1. $content$, TeX delimiters for inline math -> Latex_Fragment Inline

   • cannot start/end with a space (defined behavior) https://github.com/logseq/logseq/issues/4170
   • cannot be multi-line

2. $$content$$, TeX delimiters for displayed math

   • $$ appears at the start of a line -> Displayed_Math
     • can be multi-line
     • good cases
       • Used like codeblocks
       • Only $$content$$ in one line, no other content later
     • bad case: $$content$$ content https://github.com/logseq/logseq/issues/4066
   • otherwise -> Latex_Fragment Display
     • cannot be multi-line

3. \( content \) , LaTeX delimiters for inline math -> Latex_Fragment Inline

   • cannot be multi-line

4. \[ content \], LaTeX delimiters for displayed math -> Latex_Fragment Display

   • cannot be multi-line

5. \begin{env} content \end{env}, LaTeX environment-> Latex_Environment

My improvement ideas

• Allow multi-line for all Latex_Fragment. And allow $ content $

  I'm actually interested why they don't support multi-line now. Is there a design consideration?

  By the way, I don't understand why \(\) and \[\] don't support multi-line text, since they use end_string. (Instead, $ use take_while (fun x -> x <> '$' && x <> '\r' && x <> '\n'), which banned \n explicitly

• Remove Displayed_Math since it's confusing. And in Logseq, let Latex_Fragment Display rendered in display mode.

  For $$, If there's nothing before the starting $$ and nothing after the ending $$, parse it into Latex_Fragment Display. Otherwise Latex_Fragment Inline.

i.e.,

$$a
b$$

and

$$a$$

are displayed math. But

$$a
$$b

and

$$a$$b

is equivalent to $a$b

For reference (and also an aternative), Typora's behavior:

• $$ and $ can both be multi-line
• displayed math only when used like codeblocks, i.e.,

  $$
  a
  $$

  The first two examples above are both inline math.

[xxchan]

By the way, should them be added to Logseq's doc?...

[garyo]

I came across this because of seeing what I think is too-aggressive math parsing. In the US, we often need to write about finances, so:

- dinner was $41.56, and breakfast will be $12.00.

It would be great if logseq could somehow figure out that this should not be parsed as math -- maybe if the trailing (second) $ is immediately followed by digits? I know users can work around this by using \$ but that is not intuitive to me, and breaks the journaling "flow". What do you think?

[xxchan]

@garyo IIRC your example can be handled correctlu in logseq?

Because there is a space before the second $

[garyo]

Yes, you're right. I've gotten into the habit of prefixing all my $ with \ because it's hard to know exactly when it'll go into math mode, but if space before the "trailing" (every other) $ works, that is good to know! Here's a case that's unfortunately too close to math mode:

- 8 mo x $400 = $3200, vs $695+$850+$66x4x8=$3657

but if I add spaces, then it's OK (no math mode, the $ signs still show up):

8 mo x $400 = $3200, vs $695 + $850+ $66x4x8 = $3657

Was this improved some time recently? I find a lot of \$ in my md files that I can now remove and they look OK. So I guess this is less important now than I thought.

One case that could still be improved is if there is emphasis around the dollar figure:

result is $1000 or, over a longer time, **$5000**

That currently in logseq still switches into math mode.

[xxchan]

Was this improved some time recently?

This is the behavior since the very beginning, but I proposed to change it in this issue. Now I think this behavior makes some sense.

One case that could still be improved is if there is emphasis around the dollar figure

IMHO it's almost impossible to handle this case (or other similar complicated ones) correctly. Otherwise math mode won't work correctly. In theory, maybe we can add an config option to opt-out math mode (or maybe only double $$ for math mode? but that's a big breaking change), but that may bring some complexity and may have rather low priority for LogSeq. So in practice, I would suggest always add a space or a \ before $ in your use case :)