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

Previous Next

Full log

Message #32 received at 61655 <at> debbugs.gnu.org (full text, mbox):

From: Yuan Fu <casouri <at> gmail.com>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: 61655 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Wed, 22 Feb 2023 12:45:24 -0800

> On Feb 21, 2023, at 7:31 AM, Jacob Faibussowitsch <jacob.fai <at> gmail.com> wrote:
> 
>> but it's a relatively small change,
> 
> Indeed, after playing around with the syntax queries a bit more, all that is needed to implement this change is the following patch.
> 
> Note for the new faces that I populated the `:foreground` fields to match the colors for the example I showed in my first email, but maybe a better default is to leave these faces totally blank and just purely `:inherit` from `font-lock-function-name-face`.
> 
> diff --git a/lisp/font-lock.el b/lisp/font-lock.el
> index 9e944fe188a..d170123c2ca 100644
> --- a/lisp/font-lock.el
> +++ b/lisp/font-lock.el
> @@ -2026,6 +2026,16 @@ font-lock-function-name-face
>   "Font Lock mode face used to highlight function names."
>   :group 'font-lock-faces)
> 
> +(defface font-lock-function-call-face
> +  '((t :inherit font-lock-function-name-face :foreground "royalblue1"))
> +  "Font Lock mode face used to highlight function calls."
> +  :group 'font-lock-faces)
> +
> +(defface font-lock-member-function-call-face
> +  '((t :inherit font-lock-function-name-face :foreground "brightred"))
> +  "Font Lock mode face used to highlight member function calls."
> +  :group 'font-lock-faces)
> +
> (defface font-lock-variable-name-face
>   '((((class grayscale) (background light))
>      :foreground "Gray90" :weight bold :slant italic)
> diff --git a/lisp/progmodes/c-ts-mode.el b/lisp/progmodes/c-ts-mode.el
> index b7a487687a8..51a65aa6545 100644
> --- a/lisp/progmodes/c-ts-mode.el
> +++ b/lisp/progmodes/c-ts-mode.el
> @@ -529,8 +529,8 @@ c-ts-mode--font-lock-settings
>    :feature 'function
>    '((call_expression
>       function:
> -      [(identifier) @font-lock-function-name-face
> -       (field_expression field: (field_identifier) @font-lock-function-name-face)]))
> +      [(identifier) @font-lock-function-call-face
> +       (field_expression field: (field_identifier) @font-lock-member-function-call-face)]))
> 
>    :language mode
>    :feature 'variable
> 
> Best regards,
> 
> Jacob Faibussowitsch
> (Jacob Fai - booss - oh - vitch)
> 
>> On Feb 21, 2023, at 04:55, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
>> 
>> 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.
> 

Yeah that’s just an idea, and I don’t have problem adding faces. But we probably can’t keep adding more and more specific faces. At one point we’ll need to either add indirection, or ask users to just add their own fontification rules, if it is really specific. We’ll see. 

Function definition & call is totally reasonable. But adapting all the major modes to use them is might be too big a change for emacs-29.

Yuan

Previous Next

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