markup/goldmark: Render strikethrough and emojis in TOC entries

[lyind]

Configure the TOC (table of contents, toc.go) goldmark renderer instance to always enable the Strikethrough extension.

This allows handling ast.KindStrikethrough within an AST node avoiding a crash.

Fixes #7169
Fixes #8087
Fixes #11783

[jmooring]

@lyind There's a failing test, and you need to add conditions to test the issues that this PR addresses. Also, please capitalize the first letter of the commit message (after the xxx/xxx: part) per the commit message guidelines.

[lyind]

It seems like the rendering test fails, because the output is more correct now:

...
        line diff (-got +want):
            []string{
            	"<nav id=\"TableOfContents\">\n",
            	"  <ul>\n",
            	"    <li><a href=\"#a--b--c--d\">A &lt; B &amp; C &gt; D</a></li>\n",
            	strings.Join({
            		`    <li><a href="#a--b--c--d-divfoodiv">A &lt; B &amp; C &gt; D `,
            		"<",
          - 		"!-- raw HTML omitted -->foo<!-- raw HTML omitted --",
          + 		"div>foo</div",
...

But I might confuse "got" with "want", so will have another look at the code of that test case.

[lyind]

@jmooring I applied the following changes to fix the test and be more aligned in general:

• Also pass rendering options (HardWraps, XHTML, Unsafe) to the TOC rendering extension
• Last test in TestEscapeToc() (unsafe renderer): expect <div> element to correctly be excluded from the TOC output

Is my assumption correct that the test expectations were slightly incorrect, in regard to the <div> and possibly similar block elements to be passed through?

[jmooring]

Also pass rendering options (HardWraps, XHTML, Unsafe) to the TOC rendering extension

Why do we need to do this? The xhtml and unsafe options are already honored when rendering a TOC entry, and you would never have a newline within a heading so the hardWraps setting is irrelevant.

Although I have not looked into the details, I find it curious that the strikethrough and emoji extensions are not used when enabled, but the typographer extension is used when enabled. Can you explain why that is?

Here's simple but (I think) comprehensive test:

git clone --single-branch -b hugo-github-issue-11784 https://github.com/jmooring/hugo-testing hugo-github-issue-11784
cd hugo-github-issue-11784
hugo server

Neither the strikethrough nor the emoji extensions are used when rendering the TOC entry. I think we broke the emoji part when we started using yuin's extension (#11593).

[jmooring]

Let's re-task this PR to fix these open issues:

• Emoji in markdown heading is not rendered in TOC entry #12022
• Strikethrough in markdown heading is not rendered in TOC entry #7169
• Strikethrough in markdown heading triggers runtime error #11783

I've revised the test cases, replacing toc_test.go with toc_integration_test.go. The last two cases are commented out; they fail due to the first two open issues above.

https://github.com/gohugoio/hugo/blob/master/markup/goldmark/toc_integration_test.go#L255-L265

Without digging into the details, I am surprised that the typographer extension affects TOC entries, but the emoji and strikethrough extensions do not.

[lyind]

The xhtml and unsafe options are already honored when rendering a TOC entry, and you would never have a newline within a heading so the hardWraps setting is irrelevant.

True. Just passed the options down out of "stubborn completeness", will change that again.

[lyind]

These three issues should be properly fixed now, testsuite passes:

• Emoji in markdown heading is not rendered in TOC entry #12022
• Strikethrough in markdown heading is not rendered in TOC entry #7169
• Strikethrough in markdown heading triggers runtime error #11783

@jmooring Please review.

[jmooring]

Functionally this is great! Thank you.

The next step is a review by bep.