When CodeHilite is enabled, fenced_code includes the language class in list of general classes.

[Phuker]

In new version 3.3, I found that a new language class appeared in the generated HTML code block, which not exist in previous version 3.2.2.

My code:

import markdown

s = '''
```c
```
'''

extensions = ['extra', 'codehilite']
print(markdown.markdown(s, extensions=extensions))

Output with c class:

<div class="c codehilite"><pre><span></span><code>
</code></pre></div>

Then I read the docs and tried to disable pygments

configs={
    'codehilite': {
        'use_pygments': False
    }
}

print(markdown.markdown(s, extensions=extensions, extension_configs=configs))

This time it outputs:

<pre><code class="language-c"></code></pre>

My version info:

$ python3 --version
Python 3.8.5
$ python3 -m pip show markdown
pyName: Markdown
Version: 3.3
Summary: Python implementation of Markdown.
Home-page: https://Python-Markdown.github.io/
Author: Manfred Stienstra, Yuri takhteyev and Waylan limberg
Author-email: waylan.limberg@icloud.com
License: BSD License
Location: /usr/local/lib/python3.8/dist-packages
Requires:
Required-by: xxx
$ python3 -m pip show pygments
Name: Pygments
Version: 2.7.1
Summary: Pygments is a syntax highlighting package written in Python.
Home-page: https://pygments.org/
Author: Georg Brandl
Author-email: georg@python.org
License: BSD License
Location: /usr/local/lib/python3.8/site-packages
Requires:
Required-by: xxx

According to this page https://pygments.org/docs/lexers/, there are so many possibilities that the language class mess up with other class with the same name.

When pygments is disabled, the class name has a language- prefix, which is acceptable.

It would be better if we always add language- prefix, or just remove it.

Thank you!

[waylan]

As noted in the documentation

The fenced_code extension does not alter the output provided by Pygments.

Usually I would say that that is what Pygments returns so that's what you get.

However, the c class is included based on the fact that you can define additional classes as documented here. However, the language class (the first one defined) should be handled separately from that and not be included in the general list of classes. In fact, I see the same behavior when codehilite is enabled but Pygments is not installed. The same input results in this output:

<pre class="c codehilite"><code class="language-c">
</code></pre>

In this case, the error is more obvious as we have both class="c codehilite" on the pre tag and class="language-c" on the code tag. Of course, as Pygments doesn't include the language in its output, we don't see class="language-c" in Pygments' output. So, Pygments is not at fault here. We need to remove the language identifying class from the list of classes that we pass to Pygments. Actually, we probably need to remove the class from the list we pass to codehilite. So, yeah, this is a bug. Thank you for the report.

[mitya57]

FWIW, this behavior started happening with #816.

[waylan]

We also have an inconsistency between codehilite and no-codehilite when Pygments is not available. In both cases the code should be wrapped in pre and code tags. However, in the codehilite case, the extra classes are assigned to the pre tag, while in the no-codehilite case, they are assigned to the code tag.