First message here, I hope this is the right place to ask questions.
I’ve been a very happy Hugo user for a few years now, but I’ve been having issues lately with how code blocks are rendered. I’m pretty sure that this is an issue on my end and that I should be able to easily fix that issue by making some changes to the config file(s) but I can’t seem to find where.
Problem:
Say I write a code block in Markdown for a given language. In this case Python but I’m having the same issue with all the languages I’ve used:
```python
x = 1
print(x)
```
For some reason the above snippet will look like:
x = 1
print(x)
Does anyone know how to fix this please?
If you need more information, I’m using Mint and here’s the current Hugo version I’m on:
If you change the line height in the developer tools, the display doesn’t change. But what one can see in the HTML source are lots (lots!) of empty lines. Which normally doesn’t matter, but in a pre element, those are preserved, and that’s what we see in the code boxes.
How and why that comes about – no idea without seeing the source code.
So, @Loulou, please post a link to your repository.
I’m probably too dense. On this page Julien Blanchard | Explore your dataframes with PyGWalker, I set the style of the first span class="cl" element in the code block to line-height: 0.625 and don’t see any change in the code block.
The line-heightCSS property sets the height of a line box in horizontal writing modes
line-height doesn’t do anything at all for span elements:
But setting line-height on the pre.chroma element changes everything. As it should. But a value of 0.625 for line-height is ridiculous: 1.2 is considered good for legibility, half of that would have lines run into each other – if not every second one were empty.
The above sets (universally) the font size to 25.6 pixels, then reduces the font-size to 16 pixels within the html element. So the line height is based on 25.6 pixels… I think.
Yes. You set properties on *, not on span.cl. And it’s not clear if that * is inside a nested rule or not.
Anyway:
line-height doesn’t work for inline elements, only for block or inline-block.
setting a relative line-height refers to the current font-size. So, 0.625 for line-height translates to 62.5% of the font-size. Which would create overlapping lines, obviously. Unless every second line is empty, as in the case of a pre element that preserves the white space.
This is what you get if you set line-height: .625 for a p element:
On a possibly related note, I might add that I installed Hugo 3 years ago as well as the Anatole theme. And always copied / pasted that entire folder onto freshly installed OS, alongside a new install of Hugo (therefore on a higher version).
Should I just wipe out everything (just keeping the articles and images) and start over from scratch?
Not quite. .html is a more specific selector than * (which has specificity 0). So, it overrides the * setting of the font-size – nothing is accumulated or multiplied here. Which means that the font-size is set to 62,5 percent of the default for the element with class="html", which is html – be it the user-defined setting or the browser’s if the user didn’t set a preference. Which (in my case) means 11.25 px, since my preference is an 18px sized font.
So, 1rem corresponds to 11.25px (again: in my case) for this HTML document.
Now it’s getting interesting: The font-size for .html is 11.25px, but what happens with .chroma? Its 1 rem equivalent is still 11.25px, but now * {font-size: 1.6rem;}
gets applied to the .chroma because there is no other rule with a more specific selector. Consequently, .chroma has a calculated font-size of 18px (1.6 times 11.25).
Now, we apply a line-height: 1.2rem to the .chroma element, and that gets us a calculated line-height of 13.5px.
Which is indeed what the developer tools show me for .chroma:
line-height is smaller than font-size. While that gives the desired result (kind of), it’s by no means a solution to the problem (in my opinion). Which is still (in my opinion) that there are empty lines interspersed with the code lines. As the OP already mentioned in their first post, btw. In a pre element, these empty lines will be preserved, so setting a line-height much smaller than the font-size will make the empty lines visually disappear. But they are still there, in the HTML.
That’s just a band-aid. Your code blocks should not contain empty lines. Which they do.
Why? You should get to the root of the issue, namely why you have these empty lines in your code block. If it were me, I’d probably go for a different theme (and better CSS). But that’s another topic.
I get your point on the band-aid approach. My initial thought was to run a Python or Bash script that removes these empty lines on all the html files contained in the public folder. But then started looking for a proper solution on the web.
Nothing is wrong with blank lines in a code block. If you want them there. If they get inserted by whatever is processing the MD, that’s probably not desirable.
Added this to the css file in public > css and no luck
My bad for not adding in some sort of context around the ask. I just find that the extra blank lines make the code snippets difficult to read. Not so much for the articles I have on JavaScript / TypeScript, but more for the ones using Python. The indentation and blank lines don’t go well together. But that’s just my opinion.
100%, and the worst thing is that if I run hugo server -d to preview the whole site on localhost then everything looks fine.
As discussed earlier I might have messed up with some files when transferring this repo multiple times from one computer onto another.
I might do a clean-up tomorrow as I’ll be working from home.
But you have to view source (Ctrl +U) to see them. Chrome and Firefox hide the blank lines when you use their dev tools to inspect the HTML… which isn’t great. Lesson learned.
As to why you have blank lines? I have no idea. Hugo doesn’t do it by default. I can only reproduce the problem by doing something dumb like this:
