Josh Goebel

It seems either we need to run the grammars at built time (which seems icky), or make the aliases static meta-data in the comment header... but that would break the...

``` { className: 'string', variants: [ { begin: /b?r(#*)"(.|\n)*?"\1(?!#)/ }, { begin: /b?'\\?(x\w{2}|u\w{4}|U\w{8}|.)'/ } ] }, ``` I'm guessing `.` doesn't cover Emoji... I'd have to play around with this...

Lets add a markup test for this as well, and would this also make sense to apply to C?

Well if they are truly personal, just use them... it's only the core library that we aren't allowing them in v11 because of semantic versioning. I haven't had much time...

Sadly, we cannot use negative look behind yet as that feature is still too newly added to Safari.

Actually, hold that thought, perhaps it's time to change this policy: https://github.com/highlightjs/highlight.js/issues/3890

No lookbehind for now as it would be a breaking change... why not just have a single (separate) rule that matches `\*` but then chooses not to highlight it? Would...

We're always happy to see a PR for an issue, it doesn't need to first be assigned.

Oh my bad for not reading this fully. `No` is CamelCase, which is convention for classes in JavaScript. So highlighting it is the intended behavior. If you want a constant...

> no syntax to highlight --> does not get hlghlighted. > No syntax to highlight --> The word 'No' gets highlighted. These are NOT valid Javascript examples, so we do...