Closed janhuenermann closed 9 months ago
bep
commented
1 year ago LaTeX in Markdown file
What is "LaTeX in Markdown"? If this is about adding yet another delimiter for this particular syntax, why not use a shortcode (for inline latex) and code fences for block latex?
janhuenermann
commented
1 year ago LaTeX in Markdown file
What is "LaTeX in Markdown"? If this is about adding yet another delimiter for this particular syntax, why not use a shortcode (for inline latex) and code fences for block latex?
Hey @bep,
Thanks for your reply! When I mentioned "LaTeX in Markdown," I was referring to the ability to include standard LaTeX expressions directly within Markdown files using the familiar dollar-sign syntax (single $ for inline and double $$ for block expressions). This is the standard syntax in Jekyll, Jupyter notebooks, VSCode Markdown extension, on platforms like GitHub, and more, making it a widely recognized and expected feature for many users. Shortcodes however require to change Markdown files for Hugo, which is not only inconvenient but prevents users from reusing the same Markdown files across projects.
There's an in-depth discussion about this topic in the forum as well: https://discourse.gohugo.io/t/katex-in-hugo/43274
jmooring
commented
1 year ago Miscellaneous thoughts...
This syntax is supported by GitHub:
```math
\sqrt{3} # with or without delimiters
This syntax is supported by GitLab:
\sqrt{3} # must not include delimeters
The fenced code block syntax is consistent with Mermaid diagram support by both services:
xxx
#### Alternate delimiters
KaTeX and MathJax support alternate delimiters:
```text
\\[ \\] # display mode
\\( \\) # inlineThese are not supported by either GitHub or GitLab. Markdown in the wild using this syntax is not portable to either service.
With Hugo you must use a shortcode. The resulting markdown is not portable.
JS and CSS can be loaded as needed (per page) without requiring a front matter flag (i.e., .HasShortcode, .Page.Store).
For diagrams, I prefer to use the free Kroki service because it embeds an SVG---no client side rendering.
For math, I prefer to use the free Math API service because it embeds an SVG---no client side rendering. The fenced code block syntax is portable; the shortcode syntax is not portable.
dudung
commented
1 year ago I am sorry, if I do not understand the proposal. Does Hugo already support for $ for inline math and $$ for block math using KateX? I believe I have used it for a while and it is already very convenient. The missing is only refering the equation feature, but it is unsupported by KaTeX and not Hugo.
ttyS0
commented
1 year ago I am sorry, if I do not understand the proposal. Does Hugo already support for
$for inline math and$$for block math using KateX?
Hugo itself does not recognize math stuff delimited by $ and $$. More specifically, it does not register $ $$ AST nodes with the underlying markdown parser (e.g. goldmark), like what goldmark-mathjax and #7435 are doing.
I believe I have used it for a while and it is already very convenient. The missing is only refering the equation feature, but it is unsupported by KaTeX and not Hugo.
Themes shipped with MathJax support (KaTeX or something else) will probably display $ $$ math correctly.
But as a result of what I said before, taking $a^*=x-b^*$ for example:
$a^*=x-b^*$ appears in raw HTML and is captured by JavaScript math engines$a^<em>=x-b^</em>$ and math engines just won't capture, you should've guessed how it comesAlso brings similar problems mentioned in #6694 #6864 #7249. These issues will be solved cleanly once $ $$ blocks are recognized by Hugo.
ttyS0
commented
1 year ago Here is a brief survey on the status quo of different math block support among popular Markdown editors:
| Editor / Platform | ```math display |
$...$ inline |
$$...$$ display |
\( inline |
\[ display |
|---|---|---|---|---|---|
| GitHub | Yes | Yes (bugged1) | Yes (bugged) | No | No |
| GitLab | Yes | No | No | No | No |
| VSCode (w/o plugins) | No | Yes | Yes | No | No |
| Typora | No | Yes (disabled by default) | Yes | No | No |
| StackEdit | No | Yes | Yes | No | No |
| MarkText | No | Yes | Yes | No | No |
Note 1: GitHub markdown preview is also bugged, which does not treat contents inside $ $$ as a block. Stuff like $\{a\}$ also won't work.
$ $$ and other stuff mess Markdown a lot at first, but by inspecting the column, dollars are de facto delimiters for math blocks now in popular Markdown editors. If Hugo supports dollar signs (or even make the delimiter configurable), it will increase much in interopability.
pilgrimlyieu
commented
1 year ago I think it'll be better if there's an way to configure the delimiters since \(...\) and \[...\] seems better than $...$ and $$...$$.
Reference
aurelienpierre
commented
1 year ago I don't understand this issue. I have LaTeX working properly in Hugo by loading Matjax JS.
In a script.html partial, going at the end of the page, I have :
{{ if .Params.latex}}
<script>
MathJax = {
packages: {'[+]': ['autoload', 'require']},
tex: {
tags: 'all',
inlineMath: [ ['$','$'] ],
displayMath: [ ['$$','$$'] ],
processEscapes: true,
processEnvironments: true,
processRefs: true,
},
svg: {
mtextInheritFont: true,
merrorInheritFont: true,
mathmlSpacing: false,
skipAttributes: {},
exFactor: .5,
displayAlign: 'center',
displayIndent: '0',
fontCache: 'global',
localID: null,
internalSpeechTitles: true,
titleID: 0
},
options: {
ignoreHtmlClass: 'no_math',// class that marks tags not to search
processHtmlClass: 'math', // class that marks tags that should be searched
}
};
</script>
<script type="text/javascript" id="MathJax-script" async src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-svg.js"></script>
{{ end }}Note that the config script lets you decide what delimiters you want. Then, on the .md files, I write typical LaTeX equations, using the dollar syntax. In the frontmatter of pages using maths, I set latex: true to avoid loading the heavy MathJax lib everywhere if it's not needed. After that, equations are rendered client-side with no issue.
jmooring
commented
1 year ago @aurelienpierre
This will fail:
$$
\begin{array} {lcl}
L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
\rightarrow x_1
\rightarrow x_0)G(x_1
\longleftrightarrow x_2)f_r(x_3
\rightarrow x_2
\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
\\\\\\ &=&
\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
\rightarrow x_i
\rightarrow x_{i-1})G(x_i
\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
\longleftrightarrow x_{k-1})L_e(x_k
\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
\end{array}
$$Ampersands are converted & and paired underscores create em elements. And that is the correct rendering behavior when converting markdown to HTML.
aurelienpierre
commented
1 year ago Right, now that you mention it, I remember that I had to extend PHPMarkdown to discard LaTeX in order to handle those corner cases for WordPress.
yuin
commented
1 year ago @bep @jmooring Author of the goldmark here. I've created a new (currently experimental) extension : goldmark-dynamic. This extension allows you to write a goldmark extension in Lua and load it at runtime without re-compilation. This extension may be worth to evaluate for this kind of feature requests(want to add a xxx goldmark extension).
j2kun
commented
10 months ago A big +1 here: I had tried to migrate my enormous Wordpress math blog to Hugo five years ago (see https://github.com/gohugoio/hugo/issues/5431), and LaTeX had a similar problem with the old markdown parser (blackfriday). This was the main blocker that stopped my migration.
The original comment in this issue https://github.com/gohugoio/hugo/issues/10894#issue-1665121600 has an implementation. Is there any opposition to refreshing it for the current build and opening a PR? If @janhuenermann isn't able to do it I can give it a swing.
jmooring
commented
10 months ago I think this proposal needs to be refined before it has a chance of being accepted. Adding support for LaTeX in markdown is a bit vague. Related forum topics and issues:
The vast majority of these topics (71) and issues (33) are related to the subset of LaTeX that is used to display mathematical expressions and equations.
Assuming this issue is limited to math, it seems like there are three methods for displaying these in the browser:
Although methods 1 and 3 are possible today with shortcodes and/or code block render hooks, a primary driver in all of this seems to be portability with respect to importing content (e.g., "migrate my enormous WordPress math blog to Hugo", import from Obsidian, import from Typora, etc.). In this context, shortcodes and code block render hooks are not a great option.
Questions:
Testing:
git clone --single-branch -b hugo-github-issue-10894 https://github.com/jmooring/hugo-testing hugo-github-issue-10894
cd hugo-github-issue-10894
hugo server[^1]: This extension renders (output) both MathML and KaTeX markup. It renders the KaTeX markup if the KaTeX CSS (no JS required) is loaded, falling back to MathML, but the MathML is a bit buggy.
erincatto
commented
10 months ago I would love to see Method 1 supported. I'm quite happy with KaTeX for my site. I'm currently using an old version of Hugo that supported mmark for this reason. That let me write markdown like this:
A point $$x$$ is on the plane if
$$n \cdot x = w$$
Now define a transform $$A$$ as
$$ A := (R, p) $$
where $$R$$ is an orthonormal rotation matrix and $$p$$ is a translation vector.@erincatto Your examples (assuming they are correct) highlight one of the tricky details here. You are using $$ to delimit inline math, but in most implementations that denotes display mode (block instead of inline). We also need to support display mode over multiple lines, and display mode delimiters on their own lines.
erincatto
commented
10 months ago Looks like this is configurable now: https://katex.org/docs/autorender.html
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.9/dist/katex.min.css" integrity="sha384-n8MVd4RsNIU0tAv4ct0nTaAbDJwPJzDEaqSD1odI+WdtXRGWt2kTvGFasHpSy3SV" crossorigin="anonymous">
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.9/dist/katex.min.js" integrity="sha384-XjKyOOlGwcjNTAIQHIpgOno0Hl1YQqzUOEleOLALmuqehneUG+vnGctmUb0ZY0l8" crossorigin="anonymous"></script>
<script defer src="https://cdn.jsdelivr.net/npm/katex@0.16.9/dist/contrib/auto-render.min.js" integrity="sha384-+VBxd3r6XgURycqtZ117nYw44OOcIax56Z4dCRWbxyPt0Koah1uHoK0o4+/RRE05" crossorigin="anonymous"></script>
<script>
document.addEventListener("DOMContentLoaded", function() {
renderMathInElement(document.body, {
// customised options
// • auto-render specific keys, e.g.:
delimiters: [
{left: '$$', right: '$$', display: true},
{left: '$', right: '$', display: false},
{left: '\\(', right: '\\)', display: false},
{left: '\\[', right: '\\]', display: true}
],
// • rendering keys, e.g.:
throwOnError : false
});
});
</script>@erincatto Yes, both KaTeX and MathJax are configurable. But if we use/create a Goldmark extension to avoid mangling equations that contain ampersands, matching underscores, or sequential backslashes, we need to code or configure the Goldmark extension accordingly. I suspect all of the following are used in the wild:
$...$$$...$$\(...\)\[...\]And with display (block) mode, the delimiters can be on separate lines, and the content (equation) can span several lines.
Test cases:
git clone --single-branch -b hugo-github-issue-10894 https://github.com/jmooring/hugo-testing hugo-github-issue-10894
cd hugo-github-issue-10894
hugo serverMy understanding aligns with https://github.com/gohugoio/hugo/issues/10894#issuecomment-1880111984
To my knowledge, nobody is asking for document management features of LaTeX beyond "math mode," and the MVP for supporting this is to pass any math mode expressions unchanged through hugo, and let client-side JS render the result. This is what I intended to get working in https://github.com/gohugoio/hugo/pull/11866, though I need to add a few more tests for delimiters that span multiple lines, and escaping $. This feature would cover the vast majority of the demand for "LaTeX" support in hugo, though there is a nontrivial minority of users who want html-based solutions like MathML.
I suggest the following approach to implementing the feature:
\$ as a fence start/end.[markup.goldmark.extensions] latex = true, and have it disabled by default (reasoning: most users should not have to escape $, math writers already know they need to do this).I suspect there is little demand for (4), since anyone who uses $-fenced systems like LaTeX is accustomed to these fences and their corresponding quirks (e.g., escaping $ in non-math-mode text).
As @jmooring mentioned, https://github.com/gohugoio/hugo/issues/10894#issuecomment-1880124603 uses display mode inline, but the above outline suggests that it's not hugo's job to care about this. The text is left unchanged, and the user is responsible for ensuring their JS library is configured to render the text they wrote as they desire.
Although methods 1 and 3 are possible today with shortcodes and/or code block render hooks, a primary driver in all of this seems to be portability with respect to importing content
While compatibility is important, I would add that those of us who write math-heavy documents, writing {{% math %}}n{{% /math %}} around each inline equation is simply too much overhead, and scripting around the problem is probably more work than implementing the feature upstream.
jmooring
commented
10 months ago As scoped above this feature isn't about typesetting, LaTeX, or math.
Instead, it is a generic mechanism to bypass rendering of the markdown between and including opening and closing delimiters. And that's fine, but I think the configuration/naming should be generic as well.
If we do this as a Goldmark extension, use a generic name and make the delimiters configurable. For example, if we were to name it "bypass" (hopefully something better[^1]) instead of "latex", the default configuration would be:
markup:
goldmark:
extensions:
bypass:
enable: false
delimiters:
- ['$','$']
- ['$$','$$']
- ['\(','\)']
- ['\[','\]']The default delimiters above aren't generic, but it will make the (presumably) primary use case easier to configure.
Alternatively, instead of an extension, we could configure it under the existing parser key, but I think that might get a bit busy. The default configuration for the parser key is currently:
markup:
goldmark:
parser:
autoHeadingID: true
autoHeadingIDType: github
wrapStandAloneImageWithinParagraph: true
attribute:
block: false
title: trueIn short, I think the feature should describe what it does, not what it can be used for.
[^1]: Other ideas: bypassRendering, bypassBlocks, skipBlocks, rawPassThrough, etc.
j2kun
commented
10 months ago On board with all that! I can update my PR this week.
For naming, how about "parseAsPlaintext" or "plaintextBlocks"?
jmooring
commented
10 months ago Existing extensions, both built-in and third-party, are named with nouns not verbs. And the Goldmark README uses the term "raw", so I'm leaning towards something like "rawBlocks". Write a README for the extension and see what works best:
https://tom.preston-werner.com/2010/08/23/readme-driven-development.html
Also see new issue title.
However, I wouldn't spend any time on the PR unless this proposal is accepted by bep.
jmooring
commented
10 months ago Also, given that this is generic and not tied to Hugo in any way, would it better to write this as a stand-alone, third-party extension that anyone can use, then integrate with Hugo as we have with other extensions? Not sure which would be best, but the config structure will be fine either way.
In relation to Hugo's content security policy, I think this is harmless. With the HTML output format, this:
$<script>alert('pwned');</script>$is rendered to this:
<p>$<script>alert('pwned');</script>$</p>due to Go's html/template package. Whatever we pass through is not cast to template.HTML.
j2kun
commented
10 months ago third-party extension
I can't seem to find any information in the hugo docs about third-party extensions. Could you point me to a guide or example?
@bep any thoughts on the proposal?
jmooring
commented
10 months ago I meant write as a Goldmark extension, similar to https://github.com/yuin/goldmark?tab=readme-ov-file#list-of-extensions.
j2kun
commented
10 months ago I can write it as a third-party goldmark extension if desired
erincatto
commented
10 months ago There is already a Goldmark KaTeX extension. How can I use this with Hugo?
jmooring
commented
10 months ago @erincatto You cannot enable arbitrary Goldmark extensions; only those that have been integrated.
bep
commented
10 months ago This:
$$
\begin{array} {lcl}
L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
\rightarrow x_1
\rightarrow x_0)G(x_1
\longleftrightarrow x_2)f_r(x_3
\rightarrow x_2
\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
\\\\\\ &=&
\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
\rightarrow x_i
\rightarrow x_{i-1})G(x_i
\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
\longleftrightarrow x_{k-1})L_e(x_k
\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
\end{array}
$$Can be rewritten to:
{{< raw >}}
\begin{array} {lcl}
L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
\rightarrow x_1
\rightarrow x_0)G(x_1
\longleftrightarrow x_2)f_r(x_3
\rightarrow x_2
\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
\\\\\\ &=&
\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
\rightarrow x_i
\rightarrow x_{i-1})G(x_i
\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
\longleftrightarrow x_{k-1})L_e(x_k
\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
\end{array}
{{< /raw >}}Assuming there is a raw shortcode that just prints .Inner.
Am I missing something?
jmooring
commented
10 months ago Yes, you can you use shortcodes and render hooks to pass .Inner through as-is, but that approach is not portable (import or export), standard, or easy to use. This enhancement is a good idea, enabling a capability that has been requested by many users for many years.
https://discourse.gohugo.io/tag/typesetting https://github.com/gohugoio/hugo/issues?q=label%3A%22Feature%3A+Typesetting%22
I don't see any downside.
j2kun
commented
10 months ago @bep the objection is that math prose often uses dozens of inline math blocks in a paragraph of text, many of whose .inner is just a few characters, and in this case such long short codes are tedious to type and read. It also adds a compatibility obstacle for importing and exporting to other systems that understand TeX-style math mode fences. In other words, the objection is to the verbosity of the short code fence for math-heavy text (tedious) and its difference from standard math fences (compatibility).
bep
commented
10 months ago Yes, you can you use shortcodes and render hooks to pass .Inner through as-is, but that approach is not portable (import or export), standard, or easy to use.
How portable/standard is this?
$$
\begin{array} {lcl}
L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2
\rightarrow x_1
\rightarrow x_0)G(x_1
\longleftrightarrow x_2)f_r(x_3
\rightarrow x_2
\rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2}
\\\\\\ &=&
\prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1}
\rightarrow x_i
\rightarrow x_{i-1})G(x_i
\longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k
\longleftrightarrow x_{k-1})L_e(x_k
\rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)})
\end{array}
$$Yes, you can you use shortcodes and render hooks to pass .Inner through as-is, but that approach is not portable (import or export), standard, or easy to use.
How portable/standard is this?
$$ \begin{array} {lcl} L(p,w_i) &=& \dfrac{1}{N}\Sigma_{i=1}^N(\underbrace{f_r(x_2 \rightarrow x_1 \rightarrow x_0)G(x_1 \longleftrightarrow x_2)f_r(x_3 \rightarrow x_2 \rightarrow x_1)}_{sample\, radiance\, evaluation\, in\, stage2} \\\\\\ &=& \prod_{i=3}^{k-1}(\underbrace{\dfrac{f_r(x_{i+1} \rightarrow x_i \rightarrow x_{i-1})G(x_i \longleftrightarrow x_{i-1})}{p_a(x_{i-1})}}_{stored\,in\,vertex\, during\,light\, path\, tracing\, in\, stage1})\dfrac{G(x_k \longleftrightarrow x_{k-1})L_e(x_k \rightarrow x_{k-1})}{p_a(x_{k-1})p_a(x_k)}) \end{array} $$
It may look silly, but this sub-language of LaTeX has been standard math typesetting for at least 30 years. It predates the web.
jmooring
commented
10 months ago GitHub markdown using $...$ and $$...$$ delimiters:
https://gist.github.com/jmooring/f649aae89a2047e44541de2e3001fb0b
GitLab markdown using $...$ and $$...$$ delimiters:
https://gitlab.com/-/snippets/3637801
The long multiline example above is something I created as a worst case example,similar to the old browser "acid" test. It's portable to some systems but not to others.
When authoring in things like Obsidian or Typora, the $...$ and $$...$$ is standard.
erincatto
commented
10 months ago $$ is very portable. I'm able to paste it directly into a LaTeX document. (there are some bugs in that particular sequence though).
I think shortcodes are fine for separate, displayed blocks of math. They are quite bad for inline math. It is common in mathematical writing to refer to many single character math symbols within a single sentence. Adding lots of inline shortcodes hurts readability for the author.
jmooring
commented
10 months ago Also, a shortcode that just prints .Inner pokes a hole in our content security model:
This:
{{< math >}}<script>alert('pwned!')</script>{{< /math >}}is rendered to this:
<script>alert('pwned!')</script>With this proposal, the raw markdown between and including the delimiters is not cast to template.HTML, so Go's html/template package does its job. This:
$<script>alert('pwned');</script>$is rendered to this:
<p>$<script>alert('pwned');</script>$</p>When using a shortcode for this, site and theme authors need to remember to do this for their typesetting/LaTeX/math shortcode and render hook.
{{ .Inner | htmlEscape }}OK, I didn't know that GitHub/lab actually supported this. I have not read the entire discussion, but I assume that one such extension does not already exist for Hugo, and that:
I suggest we
hugo-goldmark-extensionshugo-goldmark-extensions/insert-name-hereIf someone can help me with a name for this particular extension, I can create it and we can talk about who want to implement it.
But the scope is _blocks_ ala the GitHub example, right?
jmooring
commented
10 months ago 1) There are no existing extensions that do what we need. Those that do exist exceed the scope of this proposal, are opinionated, and in some cases impede performance.
2) Yes, I think the Hugo project should maintain control over this.
3) Other projects that rely Goldmark may benefit from this. Its un-opinionated and generic implementation can be used with any JS package or renderer that needs to parse raw content... math, chemistry, physics, diagrams, etc.
4) The names of the core Goldmark extensions (maintained by yuin) are singular nouns. The best name that I have come up with so far is rawBlock, but others may have better ideas.
But the scope is blocks ala the GitHub example, right?
I'm not sure exactly what you mean, but the "blocks" that will bypass markdown processing may be inline, block, single line, or multiline. An important note is that the delimiters themselves are not swallowed; they are part of the "block".
Finally, the proposed default configuration for this is:
markup:
goldmark:
extensions:
rawBlock: # or a better name
enable: false
delimiters:
- ['$','$'] # inline equations
- ['$$','$$'] # block equations
- ['\(','\)'] # inline equations
- ['\[','\]'] # block equationsI'm not sure exactly what you mean,
It's the title of this issue, "raw content blocks". Is that the scope of this discussion?
$$
This is a block.
$$
This is $inline$.IMO inline would need to be in scope as well as blocks. Maybe rawContent would be sufficiently expressive?
jmooring
commented
10 months ago Is that the scope of this discussion?
Yes, as well as the other common/standard[^1] delimiting pairs as shown in the proposed default configuration above.
\[
This is a block.
\]
\[This is a block.\]
This is \(inline\).Note that block equations may have the delimiters on the same line, or on the preceding and following lines. I have not seen the two mixed. For example, I don't think we need to worry about these:
$$This is a block
$$
This is $inline
$[^1]: The bracket/parentheses delimiters are less common, but both are included in the KaTeX and MathJax documentation. While the body's open...
bep
commented
10 months ago OK, but then the name rawBlock is maybe not great.
What about hugo-goldmark-extensions/passthrough?
markup:
goldmark:
extensions:
rawBlock: # or a better name
enable: false
delimiters:
- ['$','$'] # inline equations
- ['$$','$$'] # block equations
- ['\(','\)'] # inline equations
- ['\[','\]'] # block equationsI suspect that the implementation need to distinguish between block and inline delimiters, but time will tell.
jmooring
commented
10 months ago hugo-goldmark-extensions/passthrough
Perfect.
bep
commented
10 months ago OK, I have created https://github.com/gohugoio/hugo-goldmark-extensions -- I suggest we take implementation specific discussions somewhere inside that repo.
github-actions[bot]
commented
8 months ago This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Continuing the discussion from https://github.com/gohugoio/hugo/pull/10888 and the forum.
Hey everyone,
Following up on the PR, I wanted to open an issue to discuss an improvement to LaTeX support in Hugo. Standard LaTeX in Markdown support has been requested by the community for a while, especially among the scientific blogging community. However, Hugo only supports a special syntax that requires modifying existing Markdown files to work with Hugo. Platforms like GitHub already support the standard dollar-sign syntax, e.g. that's an inline expression: $x^2$.
Here's the proposal:
This is already implemented here: https://github.com/janhuenermann/hugo-katex/commit/ad382464769740c73235cbc3b20c4a5143408aa2
Looking forward to hearing your thoughts on this!