Add support for chroma lexer overrides #11496
Comments
|
An alternative idea for dealing with this is to use the approach used by hugo for diagrams - https://gohugo.io/content-management/diagrams/ along with prism.js. I wanted to add some custom syntax highlighting in a code block - I want the word "when" to be treated as a keyword and for it to be highlighted as well. Add a custom code block render hook - {{- $content := .Inner -}}
<pre class="language-boc">
<code class="language-boc" style="margin: 0; padding: 0;">
{{- $content | htmlEscape | safeHTML -}}
</code>
</pre>
{{ .Page.Store.Set "hasBoCCode" true }}Extend prism (more detail on how to do that) by adding support for my custom syntax highlighting by adding the following file at Prism.languages.boc = {
keyword: /\b(when)\b/,
// 'function': /\b\w+(?=\()/,
// 'string': /"(?:\\.|[^\\"])*"/,
// 'number': /\b\d+\b/,
// 'comment': /\/\/.*/
};Updating the baseof template to import the prism scripts <!--...-->
<head>
<!--...-->
{{ if .Store.Get "hasBoCCode" }}
<link
rel="stylesheet"
href="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/themes/prism.min.css"
/>
<script src="https://cdnjs.cloudflare.com/ajax/libs/prism/1.29.0/prism.min.js"></script>
<script src="/js/prism-boc.js"></script>
{{ end }}
<!--...-->The only drawback of this approach is that this will break highlighting for all other code blocks if the prism scripts are loaded (which for me wasn't an issue but isn't particularly ideal). Another drawback is that the renderring is happening client side |
|
I'm closing this for now. This ball may be picked up again in the future, but I don't want to add/maintain more complexity to a setup that works great for 99.999% of the use cases. |
|
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. |
As I understand, hugo uses chroma "out of the box". That is, it uses the lexers that are embedded/compiled into https://pkg.go.dev/github.com/alecthomas/chroma/v2. Albeit via a shim of the registry in
github.com/gohugoio/hugo/markup/highlight/chromalexers.For well-established languages this is fine, because they (hopefully) change infrequently.
We have just submitted (and had merged) an initial version of the CUE lexer: alecthomas/chroma#858
My understanding is that the process of support for
.cuefiles making its way through to hugo is now that:This is quite a lengthy process, especially where tagging new versions is involved.
Given the initial version of the CUE lexer is not yet complete, it is likely that more changes/bug fixes will be required.
Having each such change go through the pipeline above places a large burden on the maintainers of the chroma and hugo projects.
It also means that iteration on the CUE lexer in a hugo-based environment requires incredibly long cycles of pushing the change through the "pipeline".
A short-term focussed way of shortening that pipeline would be to add configuration to hugo that allows for overrides to the chroma lexer defaults to be specified as filepaths.
This would allow us to:
.cuefilesHaving briefly looked at the code, hugo already wraps the default chroma lexer registry in
github.com/gohugoio/hugo/markup/highlight/chromalexers. So the configuration would drive the concept of an overlay within that package.Would welcome thoughts/feedback on the suggestion, as well as ideas for alternative ways of dealing with this.
The text was updated successfully, but these errors were encountered: