Polyglot syntax highlighting not working?

[okmaybenot]

Syntax highlighting works great for Clojure, I read in the book that it should work for other languages ​​too. (but probably ::clerk/opts should be ::clerk/render-opts)

Unfortunately, when I tried to use this feature, I could only get it to work for Forth, which is very strange. Maybe I'm doing something wrong?

Any help would be appreciated

Clerk version: io.github.nextjournal/clerk {:mvn/version "0.17.1102"}
Clojure version org.clojure/clojure {:mvn/version "1.11.1"}

I'm using simple md notebook with code blocks

def hello():
  print("world");

And I see in the network tab that relevant parsers are loading.

Interestingly syntactic tree for python, c++, js, etc looks very simple compared to clojure, so i guess smth is wrong here.

[zampino]

I think there's 2 issues here:

1. as observed by @romanatexn options should be passed as ::clerk/render-opts, I thought we normalise from the older version but we no longer do that.
2. even with that in place, our codemirror highlighting has been messed up with some dependency update. I used the markdown fences notebook to bisect where language options are passed down correctly, last good is dc51320f and first bad is 93e21941 (93e2194).

That said, we're importing code mirror language-data dynamically and that's already the latest version available. So I'll keep checking other options.

[zampino]

In fact 93e2194#diff-cc47688828e6345582744b8a90a5b22ee617035b69c25d7861f47499ab386793 bumped language-data. The previous version just cannot be restored because is no longer compatible with the codemirror stack we have now...

[zampino]

Dug a bit deeper around this. With the new versions, I couldn't have the language-data module from CDN work with the rest of the codemirror libraries from the shadow bundle. It wouldn't be the first time I see dependencies loadeded from different sources blow up instance checks in codemirror.

However I made a quick experiment showing that if we build the language-data module with shadow-cljs (from the same environment and host it ourself over CAS, say) then a dynamic import of this one would work just fine. Maybe hosting the module ourself like we do for the viewer bundle isn't a bad idea in general.