tpl/transform: Expose the KaTeX strict option

[jmooring]

The issue description may not be true in all cases, but this fails:

{{ transform.ToMath `line1\\line2` (dict "displayMode" true) }}

execute of template failed at <transform.ToMath>: error calling ToMath: not a function

This works as expected:

{{ transform.ToMath `line1\\line2` (dict "displayMode" false) }}

The display mode example above works as expected when using katex.js for client side rendering, and it also works with the sandbox on the katex.org website.

[jmooring]

When I run the KaTeX client (npm install katex)...

./node_modules/.bin/katex -d -i ./in.txt -o out.txt && cat out.txt

I get this message:

LaTeX-incompatible input and strict mode is set to 'warn': In LaTeX, \\ or \newline does nothing in display mode [newLineInDisplayMode]

See the (surprising) KaTeX documentation for the strict option:

A second category of errorCodes never throw errors ...newLineInDisplayMode.

Here's how Hugo currently behaves:

When strict is set to warn (the default):

1. We throw the "not a function" error regardless of error code
2. There's nothing in the logs when running with the --logLevel info flag

When strict is set to ignore:

1. We don't emit any warnings or errors regardless of error code
2. There's nothing in the logs when running with the --logLevel info flag
3. We render the expression as desired (KaTeX is forgiving), despite the invalid syntax

When strict is set to error:

1. We throw an error, but only for error codes other than newLineInDisplayMode
2. There's nothing in the logs when running with the --logLevel info flag
3. We render the expression as expected given the invalid syntax

---

Note to self about testing: remember to clear the misc file cache between runs if you're modify the codebase.

[jmooring]

@bep Given the above, I think we should either:

1. Hardcode the strict option to error, or
2. Expose the strict option with a default of error

[bep]

My instinct would be to start with

Hardcode the strict option to error, or

[jmooring]

Rethinking this, I will expose the strict option but only document the "error" (our default) and "ignore" options. This gives users the option to make ToMath behave more like MathJax.

The ability to capture and display warnings when strict is set to "warn" is a separate issue. See #13735.