-
Notifications
You must be signed in to change notification settings - Fork 3.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support Prism.js grammar parsing but use the Highlight.js HTML/theme pipeline #3619
Comments
@RunDevelopment If I wanted to package this as a small stand-alone ESM module, would I just (not caring about CJS for this ATM) Or perhaps Thoughts? Actually I don't even know if Prism is ESM client-side yet, perhaps not? |
We are going to be. ESM is very much planned as the only module system. We are likely also going to have monolithic files for compatibility, but that's about it.
Hopefully not. Prism v2 will be very explicit about instances. One of the problem we had with v1 was that So the // Take a Prism instance and the id of the language to adapt.
function fromPrism(prism: Prism, id: string) {
return function(hljs) {
return {
__emitTokens(code, emitter) {
let grammar = prism.components.getLanguage(id)
if (!grammar) {
// Decide how to handle missing grammars. I'm just gonna create an empty grammar.
grammar = {}
}
const tokens = prism.tokenize(code, grammar)
prismTokensToEmitter(tokens, emitter)
}
}
}
}
// or
// Take a component proto and add it to your own Prism instance.
function fromPrism(proto: import("prismjs").ComponentProto) {
const prism = getHLJSPrismInstance()
prism.components.add(proto)
// same as the above
return fromPrism(prism, proto.id);
} Also, language grammars are lazily evaluated in v2. They might even be re-evaluated later because of optional dependencies. So no matter what, your API must not take grammar objects. Use either ids or component protos. |
I'm not sure this would be a thing (or that I see the need?) If someone wanted a single prism instance they should just create one and always use it with If they wanted to get the prism instance "attached" to a specific grammar we could expose those on the returned grammar object and then could just query it: hljs.getLanguage("javascript")._prismInstance |
Same. I just wanted to show how an API that only takes a component proto would be implemented. I just wasn't sure in which direction you want to take this. |
I'm not sure. I'm hopeful someone comes along who's interested in the capability. I'm not really looking to maintain further pieces of HLJS outside of core... so right now we'd need a good reason to have it in core - or it's fair game for anyone who wants to come along and just make a minimal wrapper library and release it. Right now it definitely feels like more of a plugin/add-on. Long term I'm very curious what support like this will do for the bigger picture. And of course it already works - I tested it. It just needs to be packaged up nicely with some tiny amount of docs, etc... (and of course the scope <-> class mapping effort) I'm currently slightly more interested in wrapping CodeMirror's JSX/TSX Lexer since JSX/TSX is (IME) so hard to get right with pure regex and not a full parser. Though that's a size price to be paid for all that power. |
Related #2212.
I'm not sure this belongs in core yet, and I don't necessarily want a hard or soft Prism dependency. I suppose perhaps you could also pass
Prism
into the function itself though so it's late binding?Caveats
Emitter
API is public yet. Hence the__emitTokens
name of the property.What needs to be done
prismTypeToScope
functionExample Usage
To replace our JavaScript support with Prism's:
Code
The text was updated successfully, but these errors were encountered: