Skip to content

Conversation

@melisgl
Copy link
Contributor

@melisgl melisgl commented Jun 6, 2025

Also, parameterize the output markers.

Also, parameterize the THML output markers.
@melisgl
Copy link
Contributor Author

melisgl commented Jun 6, 2025

I added support for $x$ and $`x`$ syntax (rendered here as $x$ and $x$). The previous inline syntax $$x$$ (rendered here as $$x$$) also works as inline math within a paragraph and display math as a block element. I also added tests.

@melisgl
Copy link
Contributor Author

melisgl commented Jun 8, 2025

Hold on. Escaping is missing.

@melisgl
Copy link
Contributor Author

melisgl commented Jun 8, 2025

In Pandoc's tex_math_dollars extension, the dollar sign can be escaped with a backslash:

\$x_0\$

Same thing in GitHub Flavored Markdown (GFM) renders as $x_0$. However, adding a zero-width space just before the first backslash escape as in ​\$x_0\$ (obviously, the zero-width space is not readily visible) works for both Pandoc and GitHub: ​$x_0$.

Thus, the solution I'm proposing is the support backslash escape $ signs when parsing and emit backslash escaped dollar signs when needed plus the zero-width space for GFM.

@melisgl
Copy link
Contributor Author

melisgl commented Jun 8, 2025

I pushed a new version, that parses escapes properly. However, printing seems to have no provision for extended escape chars or am I missing something?

Works with inline math:

    $x_0$
    $`x_0`$
    $$x_0$$ text

and block (display) math:

    $$x_0$$

- To avoid rendering "between $5 and $6" with inline math, both the
  opening and the closing $ character must be followed / preceded by
  a non-space character. This agrees with Pandoc. The other forms do
  not have such restriction.

- In the block format, the opening $$ can only be preceded by
  spaces, and the closing $$ can only be followed by spaces on its
  own line.
@melisgl
Copy link
Contributor Author

melisgl commented Jun 9, 2025

This latest version does proper escaping in printing too, but it does not yet have the zero-width space workaround for the lack of escaping $ on GitHub. Shall I include that in the change? I can add this workaround in PAX, too.

@3b 3b merged commit e111eba into 3b:master Jun 13, 2025
1 check failed
@3b
Copy link
Owner

3b commented Jun 13, 2025

not sure about the github escaping thing, maybe with an option to disable it?

@melisgl
Copy link
Contributor Author

melisgl commented Jun 13, 2025

The zero-width space implementation wouldn't fit nicely into the existing escaping logic, and it needs the output stream to be unicode capable . I think I'll implement this in PAX after all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants