RFC: Minimum PHP version for highlight.php 10

[allejo]

RFC: Minimum PHP version for highlight.php 10

[allejo]

Since there are no critical features from PHP 7 required to maintain this library. At the moment, highlight.php 10.0.x is planning on having PHP 5.6 be the minimum requirement since WordPress reports that PHP 5.6 is still being used significantly at the time of writing this.

[joshgoebel]

Which 3rd party language do you know of using this ability?

https://github.com/highlightjs/highlightjs-shexc

[markseuffert]

We're supporting PHP 5.6 and PHP 7.x ... no specific reason, just backwards compatibility for now.

[joshgoebel]

Are all your languages just static/"compiled" versions of our original JS grammars? That should be interesting once we start adding dynamic callbacks and such things that execute actual Javascript code during the parsing (inside the grammar) to allow for smarter parsing. I'm not sure how you'd handle that auto-magically.

Dynamic grammars have also been discussed, where the grammar can self-configure at run-time.

hljs.registerLanguage("fortran", fortran, {version: "77"})
// vs
hljs.registerLanguage("fortran", fortran, {version: "90"})

Though I suppose you could do that at build time and just save static "fortran77" and "fortran90" builds, or something. Technically this is already possible, it's just not easily exposed. I know at least one of our 3rd party grammars uses that ability.

[joshgoebel]

There are breaking changes, but so far most of them are just us shifting things around that might change people using the library in very specific ways or who have hard coded file locations, etc... Someone just using the default build on a web page might not nothing, but people doing funky things with the npm library and building custom derivatives are more likely to need to make a few adjustments.

The only pure removal I saw so far is:

• remove restoreLanguageAPI (version 9 compressed languages are not compatible with version 10)

I'm not sure if you support the "compressed" version of the grammars anyways since you package them all yourself as JSON files.

---

And things like our build system changes or Javascript version requirements aren't really going to affect you at all I wouldn't think. :-)

[allejo]

Are all your languages just static/"compiled" versions of our original JS grammars? That should be interesting once we start adding dynamic callbacks and such things that execute actual Javascript code during the parsing (inside the grammar) to allow for smarter parsing. I'm not sure how you'd handle that auto-magically.

Correct, all of our languages are "compiled" versions of the original JS grammars. To be completely honest, I'm not sure how this project is going to handle callbacks; we'll have to explore options once the highlight.js v10 API is defined.

Dynamic grammars have also been discussed, where the grammar can self-configure at run-time.

hljs.registerLanguage("fortran", fortran, {version: "77"})
// vs
hljs.registerLanguage("fortran", fortran, {version: "90"})

Though I suppose you could do that at build time and just save static "fortran77" and "fortran90" builds, or something. Technically this is already possible, it's just not easily exposed. I know at least one of our 3rd party grammars uses that ability.

@yyyc514 Which 3rd party language do you know of using this ability? I have issue #58 which is exploring support for 3rd party languages.

I'm not sure if you support the "compressed" version of the grammars anyways since you package them all yourself as JSON files.

Yea, this didn't really seem to me to be beneficial for this project so we don't really have this.