Problems with syntax highlighting (hugo 0.55.5)

support
1

I’ve just started using Hugo (0.55.5). I have the following in my config.toml:

pygmentsCodeFences = true
pygmentsCodefencesGuessSyntax = false
pygmentsUseClasses = true

I’ve tried to follow the instructions for creating the syntax highligher css, which suggest running:

hugo gen chromastyles --style=<stylename> > syntax.css

…but they don’t specify where that syntax.css file is supposed to go. I’ve tried placing it both in content/ and adjacent to my config.toml. In either case, I get no syntax highlighting. As far as I can tell, it isn’t referenced by anything in the rendered content.

If I set pygmentsUseClasses = false things seem to work as expected.

How do I get syntax highlighting via classes to work? I’m using the “Ananke” theme right now.

2

Oh, I think I’ve figured this one out. The rendered content uses the baseURL setting to access CSS files. I had baseURL pointing at my blog, but of course the files don’t exist there yet because I haven’t published the Hugo version of the site.

Setting baseURL = "/" seems to have solved this particular problem.

3

If you want to load a css file or any other static file, put it in /static in your project. Hugo will simply copy those files to the root of your site.

/static/css/syntax.css
...is...
https://mysite/css/syntax.css

Then of course, you need to load it in your <head> usually by adding a line in a partial template. Or you can copy the styles to your main css.

Your idea of putting the eventual blog url in your baseURL setting was correct in the first place. Hugo’s hugo server will interpolate it correctly for local usage / viewing during dev.

4

Your idea of putting the eventual blog url in your baseURL setting was correct in the first place. Hugo’s hugo server will interpolate it correctly for local usage / viewing during dev.

That is only true when using hugo serve to serve the content. Using anything else will result in failed fetches as content refers to the baseURL setting rather than localhost. Setting baseURL to / seems to work fine in both situations, and so far does not seem to have resulted in any problems.