GNU bug report logs - #61655
[Tree sitter] [Feature Request] font-lock function calls, definitions, separately

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Yuan Fu <casouri <at> gmail.com>, jacob.fai <at> gmail.com
Cc: 61655 <at> debbugs.gnu.org
Subject: bug#61655: [Tree sitter] [Feature Request] font-lock function calls, definitions, separately
Date: Tue, 21 Feb 2023 11:55:19 +0200

On 21/02/2023 10:28, Yuan Fu wrote:
> 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.

Before we do any of that, don't we need actual different faces to use 
for e.g. function definitions and function calls?

Same for variables.

And if we have those, we might not need the indirection, at least not 
right away.

I figured we'd add them in Emacs 30, but it's a relatively small change, 
if people are interested.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.