Hmmm, yeah. The builtin tree-sitter maps syntax queries directly into
faces, where the third-party tree-sitter maps syntax queries to some
syntax types, then maps types to faces. So it would be a bit harder to
do fine-grained control like in the builtin tree-sitter, comparing to
the third-party one.
I’ve thought of this idea before but didn’t pursue it further: Right now
we allow capture names to be face names and functions, eg
(commment) @font-lock-comment-face
or
(comment) @xxx-moode-fortify-comment
Maybe we can add a third type, arbitrary symbols, like
(comment) @comment
and add a variables treesit-font-lock-mapping which maps symbols to
faces or functions:
((comment . font-lock-comment-face))
or
((comment . xxx-mode-fontify-comment))
Then we can easily support differentiating between function call and
function definition.