Code blocks not rendering properly

[nicoalba]

Hello,

New to this world so forgive my ignorance. Wasn't sure if this should go in discussion or issues but I figure it's an operator problem so I decided to post here. I'm using MkDocs w/ Material theme for documentation. Love the theme but code blocks aren't rendering properly for me even though they render just fine in my Visual Studio MD preview (and in other themes) and also in my GitLab preview.

My code:

Visual Studio MD preview:

MkDocs result:

I have messed around with indentations and spacing and all kinds of things. Any help?

[facelessuser]

Please provide your mkdocs config as I think you are missing the SuperFences plugin. Fenced code blocks are not part of the original Markdown spec, so they are not enabled by default.

[facelessuser]

You could probably do this even easier by attaching an attribute with a title and just using some CSS to add a simple title bar using that attribute's content. Of course, I would have to allow arbitrary data attributes to be attached to code blocks...

[squidfunk]

Thanks for dumping some ideas! The data attribute approach is what’s been on my mind for some time, but currently not possible due to the limitations. I guess stealing data-* attributes before pygments eats them all up could unlock a new level of flexibility.

[squidfunk]

I guess at some point we need to write a spec on all the Markdown extensions you/we added with PymdownX and Material for MkDocs 😉 it’s far beyond the original spec and proven to be very workable.

[facelessuser]

Yup, data-* has been on my mind. I need to play with it sometime soon.

[nicoalba]

I'm glad my newbness was able to spur a fruitful convo :D

[matchavez]

As requested by Martin to put here, I would find it helpful if there was a way that a code block - just the basic code block - would return the language as it is marked. I particularly like the way Typora handles this, so I'll put an example here, in images.

It should be noted that this might not be the best way, but any identification of the language would be better than having to do a super-fences workaround. I know this is somewhat discussed already, but I wanted to share a "living" example. 1,000 ways to do it visually, but of course programmatically is the tricky part, and I thank you for looking at it. 🥇

[jaceklaskowski]

I'm curious why it's important? What would that language indication bring to users? I've got no opinion on this and am simply curious what I'm missing.

[matchavez]

Well, the main reason is that as the writer of the document, you have an option to put in the language after the three backticks. There's no reason that should be hidden. If I indicate something is written, and therefore highlighted based on a language, that should not be hidden away in the markdown. Every bit of text in Markdown is used… if you put something that formats, it formats. If you write content, it displays content. This is the only thing that's content in markdown, but doesn't get rendered through by design. Specifically, you don't want to be constrained to having to do a tab structure just to point out what the language is; it's a clunky workaround.

Even if it were a hover, or something similar, that's fine. But if you identify a block, that should get rendered.

[facelessuser]

TBH, this is a behavior of Pygments. Pygments, once it is highlighted the text, doesn't need the language class in the final HTML output as it has already processed the code block. This is not true for JavaScript parsers that run on the final HTML. So Pygments does not inject the language-<code> as a class in the final output.

If anything, such requests should be presented upstream in relevant packages. For instance, if you use SuperFences (which I am the author of) it is possible that the class could be injected there. To some extent, I'd argue this to be a request for Pygments, but I've seen this request multiple times, and have been considering making something available that indicates what language the code block was specified as (whether a class of language-<code> is applied or some data-language attribute is yet to be seen).

So, I don't think this is really something for MkDocs Material to implement, but some some library upstream.

[matchavez]

So I understand exactly here, what you're saying is Pygments gets the language-lang class, uses it, and doesn't return it in any way. Given that's the case, how do you handle line numbers and highlighting? Do you read that first? If so, you'd read the lang at that same time, no? I'm sure that once it's off to Pygments, it's too late, but how do you handle linenums ?

[facelessuser]

Pygments handles line numbers. It has an option. So we (Markdown extensions -- not Mkdocs Material) pass it to Pygments. We do the same with language classes. I'm not saying we cannot intercept the language. I'm also not saying it cannot be injected. What I'm saying is:

• MkDocs Material is a theme and does not control this in any way and will not be the one that implements this desired behavior. If it was implemented, they could do something with the exposed attribute or class, but the project itself would not be the one to expose this attribute in code blocks.
• A library upstream would need to handle this and expose it in the output. It could be Pygments itself, but it could be one of the Markdown extensions that use Pygments, like SuperFences (which I am the author of). It is not impossible to do what you are requesting, but it would have to be done upstream if was to be exposed.

Anyways, hopefully, this better summarizes what I'm trying to convey.

[matchavez]

I follow you. I'll take it up with Pygments, and you guys can make it look pretty if they do it. :)

[elissasoroj]

Hello!
I'm having the same issue as the OP - but the fix doesn't seem to be the same. My code blocks aren't rendering properly, but I already have the SuperFences plugin.

Code:

Render:

mkdocs.yaml:

[facelessuser]

What if you put a new line between the header line and the code block?

[elissasoroj]

I tried all the different permutations of spaces, tabs, etc.
Turns out it's some weird issue with the local deploy. When I look at the published site everything renders fine (local deploy still doesn't):

Unfortunately that's not the end of it. On this site the code blocks are displaying, but on my other site they are not, even on the published version (both sites have more or less the same settings in the .yaml):

.yml for that site, for good measure:

[squidfunk]

You probably need to remove codehilite, as it's not supported anymore.

[elissasoroj]

that seems to have done the trick - thank you!