Adding superfences removes copy to clipboard

[edouardberthe]

Hello there,

When adding the superfences extension:

markdown_extensions:
  - pymdownx.superfences

It removes the "copy to clipboard" functionality on all the fences!
Is there something to do to prevent this?

Versions:

• python 3.6.5
• Markdown==3.1.1
• mkdocs==1.0.4
• mkdocs-material==4.6.0
• pymdown-extensions==6.2.1

Thanks

[squidfunk]

pymdownx.superfences is enabled for the official docs with a working Clipboard.js integration:

mkdocs-material/mkdocs.yml

Line 107 in 5cc68d4

- pymdownx.superfences

Please provide a reproducible example. Also, are there any JavaScript errors in the console?

[facelessuser]

SuperFences used the Highlight extension for syntax highlighting by default. Because of this, it uses the highlight class on all the code blocks.

Mkdocs-Material uses Codehilite along side SuperFences. SuperFences still uses the Highlight extension, but mirrors Codehilite options for unity. This causes the class of codehilite to be used.

Mkdocs-material identifies both codehilite and the highlight class for everything except for the clipboard which only looks for codehilite.

One day in the near future, SuperFences will stop mirroring Codehilite options when it is being used. This will fully separate SuperFences from Codehilite, which I do not use.

This theme should probably check for thehighlight class for the clipboard as well as codehilite to account for this I think. As a work around, you can configure pymdownx.highlight to use the class name codehilite.

In retrospect, I regret this temporary functionality that mirrors Codehilite options when the Highlight extension is not explicitly defined and Codehilite is. It is confusing, and the truth is, SuperFences is not really compatible anymore with Codehilite as it never uses it.

[facelessuser]

I was responding on my phone which caused a lot of typos, but I think I fixed most of them in my response now...

[facelessuser]

Example of how pymdown-extensions deals with this in it's own document config: https://github.com/facelessuser/pymdown-extensions/blob/master/mkdocs.yml#L89.

[squidfunk]

@facelessuser thanks for your detailed response. The part in question is here:

mkdocs-material/src/assets/javascripts/application.js

Lines 104 to 106 in 5cc68d4

	if (Clipboard.isSupported()) {
	const blocks = document.querySelectorAll(".codehilite > pre, pre > code")
	Array.prototype.forEach.call(blocks, (block, index) => {

So I guess we just need to change:

.codehilite > pre, pre > code

to:

.codehilite > pre, .highlight > pre, pre > code

... and we should be good.

[squidfunk]

... by the way: @facelessuser if you feel like there's an opportunity for some cleanup - happy to collaborate. It seems like you have progressed quite far on PymdownX and this theme uses old conventions or suboptimal combinations of extensions. I haven't touched the extension setup for years, would love to clean it up before the next major version.

[facelessuser]

Yup, once that change is made, there will be no risk of me abandoning the Codehilite mirroring functionality. At that point, I will cut all ties between the two extensions.

[facelessuser]

Yeah, I'll take a look sometime soon. While there have been many improvements and additions to functionality, there are few things that I think have changed to existing setup, but the full separation from Codehilite will be one...one that I've been itching to make official.

[facelessuser]

Looking over the documented supported features of pymdown-extensions, the only think that I think could be updated is that when you use SuperFences, you should probably manually specify the class to use in pymdownx-highlight (the actual highlighter used for SuperFences): https://github.com/facelessuser/pymdown-extensions/blob/master/mkdocs.yml#L88. This is only needed if you do not explicitly enable CodeHilite use, and only because MkDocs-Material doesn't support the class .highlight fully yet.

But, assuming 5.0 handles both .codehilite and .highlight fine, this won't be a big deal. And a user won't know or care that there is any difference.

History

Basically, when I first put together SuperFences, we used the highlight logic directly from CodeHilite. We began deviating from CodeHilite when SuperFences added ways to send syntax specific options which where not supported in CodeHilite. To not break people, we created our own highlighter, but would copy over CodeHilite options (if and only if CodeHilite was enabled) and pass them through our own highlighter. But it was always meant to be temporary. I've mainly held on to it because Material doesn't quite handle highlight yet. I've been meaning to do a pull request, but since I have a workaround in place (manually specifying the use of the class .codehilite) I honestly keep forgetting to do it.

Using the default class of codehilite made less sense in our new highlighter as there was no real connection except for our temporary option copying to help in the transition, so we defaulted to highlight as the default class. It was more generic.

This was great because all I used from CodeHilite was the highlighter logic itself, I never used the indented highlight style with fake shebangs. I found it not as desirable as just using fences.

Even now, CodeHilite continues to change a little, and supporting a bridge between the two becomes a little difficult, so I am glad we don't directly plug into it anymore. The next CodeHilite will allow for specifying other classes and ids when specifying in the format ```{python .other-class #id}. We do not currently support this, and while I do plan to refactor SuperFences to mimic this, it won't break me if CodeHilite releases before I get a chance to refactor to support similar logic. Updating to support this may cause some breakage in custom fence logic...

[squidfunk]

Thanks for shedding some light on this topic! I'll have a reminder to add .highlight to the query selector for v5, so we should be good to go. Also thanks for reviewing other potentials for changes and updates!

[squidfunk]

Fixed as of 4.6.1., as Markdown 3.2 now outputs pre > code syntax which matches the selectors.