The regex font-lock feature defines a rule to highlight the # marker in regex literals (#"pattern") with font-lock-property-face, using :override t to override the string feature's font-lock-regexp-face that covers the entire regex_lit node. However, the override doesn't take effect -- the # gets font-lock-regexp-face like the rest of the literal.
The query itself is correct (manually running it against the tree returns the right node), so this appears to be a tree-sitter font-lock engine issue with overriding a parent-node capture from a child-node capture in a later rule.
Options:
- Remove the regex marker rule and let the whole
#"pattern" be font-lock-regexp-face. The # is part of the regex syntax, so this is reasonable.
- Change the string rule to capture regex parts individually (marker, open, content, close) instead of the whole
regex_lit node, avoiding the override issue entirely.
- Use a different face if we fix the override.
font-lock-property-face is an odd choice for a reader dispatch character -- font-lock-delimiter-face would be more consistent with how #' and quote markers are handled.
I'm leaning towards option 1. Came across this while backfilling font-lock tests -- opening this so I don't forget to fix it eventually.
The
regexfont-lock feature defines a rule to highlight the#marker in regex literals (#"pattern") withfont-lock-property-face, using:override tto override thestringfeature'sfont-lock-regexp-facethat covers the entireregex_litnode. However, the override doesn't take effect -- the#getsfont-lock-regexp-facelike the rest of the literal.The query itself is correct (manually running it against the tree returns the right node), so this appears to be a tree-sitter font-lock engine issue with overriding a parent-node capture from a child-node capture in a later rule.
Options:
#"pattern"befont-lock-regexp-face. The#is part of the regex syntax, so this is reasonable.regex_litnode, avoiding the override issue entirely.font-lock-property-faceis an odd choice for a reader dispatch character --font-lock-delimiter-facewould be more consistent with how#'and quote markers are handled.I'm leaning towards option 1. Came across this while backfilling font-lock tests -- opening this so I don't forget to fix it eventually.