Josh Goebel

Another note, these boundaries (speaking of the magic `.` boundaries) have only ever been applied to beginKeywords... in fact I think that's a key differentiator from the normal `keywords`, but...

Further notes: The original `\b` boundaries for beginKeywords were only added as a result of deficiencies in the original parsing engine (that we have since fixed): https://github.com/highlightjs/highlight.js/commit/9dca4cc75a9832f241f981a03fcac4e2a7ff503d > Wrap "begin"...

In this case I'm not sure Java is a "fancy language"... I'll presume you're referring to the complexities of Clojure when you say "fancy". So if we want to try...

I think I'd first like to think about what makes the most sense (trying to ignore legacy) if we weren't limited technically - and then see what that type of...

Actually this is a pretty great idea: ```js { lexemes: '\.(\w+)` } ``` First capture group gets the highlight. Although most languages would need multiple `lexemes` expressions, so you could...

This thread might be one of the longer lived ones. I'm going to circle back and see about finding some temp fix to re-add the old `.` behavior to `beginKeyword`...

Please confirm which web browser or browsers you are seeing this behavior with. 

Nevermind, this is a problem with the engine itself (not browser/DOM). It can be reproduced with `highlight` easily: ```js const s = "rem line1\r\nrem line2" r = hljs.highlight(s, {language: "dos"})...

@highlightjs/core Ever run into this before? We use `/$/` to match endings a lot, which leaves the line-ending encoding (\r or \r\n) outside the match... which is good... the problem...

I feel like I'm torn between two directions: - "This is just how regex works", (that `^` and `$` pin EVERY line ending) we need to suck it up and...