This will replace the syntect usage in Zola in the next version.
This will output the exact same thing as you see in VSCode and syntaxes will be up to date! No more 5+ years old Rust grammar where it’s not highlighting things properly! Also way more supported languages/themes due to a bigger ecosystem.
I’ve just migrated my theme Zolarwind from Zola 0.21 (syntect) to 0.22 (Giallo)
and wanted to share some feedback on the migration.
Good:
The switch to TextMate / VS Code grammars feels like a big improvement to me.
Adding SystemVerilog and VHDL via extra_grammars using upstream .tmLanguage.json files works reliably once the required top-level name field is present (matching the language used after the backticks).
I’m aware these languages are now already supported, but I used them as examples and wanted to keep them instead of looking for unsupported ones.
Class-based highlighting integrates well with Tailwind when importing the generated giallo*.css into the Tailwind build.
Friction points:
I didn’t find explicit migration documentation (possibly a Layer-8 issue). Comparing the v0.21.x and v0.22.x documentation side by side did the trick.
extra_grammars paths are filesystem-relative to the site root, not to static/, which took some trial and error.
giallo*.css is always generated into static/ and copied to public/.
Since I import it into my own CSS pipeline (Tailwind), I currently have to explicitly exclude it via ignored_static in config.toml. It would be nice if the output path were configurable (unless I missed something).
Overall, I think the direction is the right one. The highlighting quality and ecosystem benefits outweigh the migration cost, and the configuration is understandable once the constraints are known.
Thanks for pushing this forward; Giallo is a step up from syntect.
Thanks for the pointer to the changelog. I had the feeling that I must have missed something.
Regarding giallo*.css being generated into static/: I can totally live with that, and I understand the rationale of “generate once, commit it, and reuse it”. The minor friction I still see is the exact location: having the file land in the root of static/ feels forced for a CSS file. Personally, I would put it under something like static/css/, if I were using it directly on the site, but that’s subjective. Using ignored_static works, so this is not a problem.
In setups where the CSS is consumed by a build pipeline (Tailwind in my case), the import ends up looking like @import "../../../static/giallo.css";. Which is functional, but not pretty. A shorter, configurable path would be nicer. Copying the file to a another location is possible, but without some synchronization you lose the guarantee of picking up changes if the generated CSS evolves in future Zola versions.
Giallo is a step up from syntect, and the highlighting improvement benefits are worth it.
This might be a nice, contained improvement for a PR at some point. I’m not fully comfortable hacking on Zola yet, but this could be a good excuse to start and learn along the way.