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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 61655 in the body.
You can then email your comments to 61655 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [Tree sitter] [Feature Request] font-lock function calls,
 definitions, separately
Date: Mon, 20 Feb 2023 10:54:42 -0500

[Message part 1 (text/plain, inline)]

Hello,

Is it possible to have the builtin tree sitter give differentiate font-locking for function calls and function definitions?

The 3rd party tree-sitter package (https://github.com/emacs-tree-sitter/elisp-tree-sitter) has this feature and it is quite nice. In fact it goes further, allowing you to additionally distinguish between builtin calls, macro calls, method calls, etc. (see https://github.com/emacs-tree-sitter/elisp-tree-sitter/blob/master/lisp/tree-sitter-hl.el).

As far as I could see, the builtin mode only provides `font-lock-function-name-face`. I have set treesit-font-lock-level to 4. 

Examples below are for C/C++ mode, but this would apply to any number of languages.

Desired (i.e. what 3rd party package produces):



Current:



Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

[Message part 2 (text/html, inline)]

[PastedGraphic-4.png (image/png, inline)]

[PastedGraphic-3.png (image/png, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>, Yuan Fu <casouri <at> gmail.com>,
 Theodor Thornhill <theo <at> thornhill.no>
Cc: 61655 <at> debbugs.gnu.org
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Mon, 20 Feb 2023 19:03:35 +0200

> From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
> Date: Mon, 20 Feb 2023 10:54:42 -0500
> 
> Is it possible to have the builtin tree sitter give differentiate font-locking for function calls and function definitions?

AFAIU, it already does.  Yuan and Theo, am I wrong?

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>, Jacob Faibussowitsch
 <jacob.fai <at> gmail.com>, Yuan Fu <casouri <at> gmail.com>
Cc: 61655 <at> debbugs.gnu.org
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Mon, 20 Feb 2023 21:24:36 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
>> Date: Mon, 20 Feb 2023 10:54:42 -0500
>> 
>> Is it possible to have the builtin tree sitter give differentiate font-locking for function calls and function definitions?
>
> AFAIU, it already does.  Yuan and Theo, am I wrong?

You're not wrong, but it depends on each implementation whether or not
the definition gets a different color or not.  Jacob, do you have any
examples where it is wrong and what you expect instead?

Theo

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

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 61655 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Yuan Fu <casouri <at> gmail.com>
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Mon, 20 Feb 2023 15:45:37 -0500

Hello All,

> Jacob, do you have any examples where it is wrong and what you expect instead?

I had attached some screen grabs in my initial email, if they don’t show up on your end they do show up on the web archives: https://lists.gnu.org/archive/html/bug-gnu-emacs/2023-02/msg01638.html.

The key differences are:

1. `foo()` (i.e. a function definition) is light-blue.
2. `bar()`, and `baz()` (function calls) are dark blue.
3. The member function call `b.mem_func()` highlights the `mem_func()` part in red.

On the other hand, the builtin tree sitter mode font-locks them all using the same light-blue color. Indeed performing M-x describe-face over each separate part yields only `font-lock-function-name-face` for builtin, while 3rd party returns separate faces (which are available to customize) for each case.

I looked through `c-ts-mode.el` as an example and found `c-ts-mode--font-lock-settings`. Treesitter already identifies all of the above cases as different nodes in the AST (as evidenced in treesit-explor-mode) so it seems that adding another set of matchers (and appropriate faces, e.g. font-lock-function-call-face)

:language mode
:feature 'label
'((call_expression
   function: (identifier) @font-lock-function-call-face))

Should do the trick no?

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

> On Feb 20, 2023, at 15:24, Theodor Thornhill <theo <at> thornhill.no> wrote:
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
>>> From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
>>> Date: Mon, 20 Feb 2023 10:54:42 -0500
>>> 
>>> Is it possible to have the builtin tree sitter give differentiate font-locking for function calls and function definitions?
>> 
>> AFAIU, it already does.  Yuan and Theo, am I wrong?
> 
> You're not wrong, but it depends on each implementation whether or not
> the definition gets a different color or not.  Jacob, do you have any
> examples where it is wrong and what you expect instead?
> 
> Theo

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

From: Yuan Fu <casouri <at> gmail.com>
To: jacob.fai <at> gmail.com
Cc: 61655 <at> debbugs.gnu.org
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function 
 calls, definitions, separately
Date: Tue, 21 Feb 2023 00:28:37 -0800

Jacob Faibussowitsch <jacob.fai <at> gmail.com> writes:

> Hello,
>
> Is it possible to have the builtin tree sitter give differentiate font-locking for function calls and function definitions?
>
> The 3rd party tree-sitter package (https://github.com/emacs-tree-sitter/elisp-tree-sitter) has this feature and it is quite
> nice. In fact it goes further, allowing you to additionally distinguish between builtin calls, macro calls, method calls, etc.
> (see https://github.com/emacs-tree-sitter/elisp-tree-sitter/blob/master/lisp/tree-sitter-hl.el).
>
> As far as I could see, the builtin mode only provides `font-lock-function-name-face`. I have set treesit-font-lock-level to
> 4. 
>
> Examples below are for C/C++ mode, but this would apply to any number of languages.
>
> Desired (i.e. what 3rd party package produces):
>
> *
>
> Current:
>
> *

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.

Yuan

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

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: Re: 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.

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

From: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Yuan Fu <casouri <at> gmail.com>, 61655 <at> debbugs.gnu.org
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Tue, 21 Feb 2023 10:31:17 -0500

> 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.

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

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

On 21/02/2023 17:31, Jacob Faibussowitsch wrote:
> but maybe a better default is to leave these faces totally blank and
> just purely `:inherit` from `font-lock-function-name-face`

I believe so.

> +(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)

This one I was thinking of as well.

> +(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)

What's a "member function"? Is it like a method? If people want this 
distinction, we can add such face. But I'm curious whether some other 
editors use different colors for these cases.

I'm also wondering what face we're supposed to use for "receiver-less" 
method calls, such as calls to the methods defined in the same class, in 
e.g. Ruby and Java. Or C++/C#. They don't use 'this'.

I think more importantly, we need a new face for variables.

font-lock-variable-ref-face ?

I also wonder whether we'll need to separate faces for properties: 
definitions vs. uses. That one we could use to do early, to keep the 
names uniform, e.g. we'd have:

  font-lock-function-name-face
  font-lock-function-call-face
  font-lock-variable-name-face
  font-lock-variable-ref-face
  font-lock-property-name-face
  font-lock-property-ref-face

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

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

> What's a "member function"? Is it like a method?

Yeah, I suppose method is the more general term for it.

> If people want this distinction, we can add such face. But I'm curious whether some other editors use different colors for these cases.

I personally do not; I brought it up because it was functionality that the 3rd party package had over stock. I think a good representative list is the one vscode offers:

https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#standard-token-types-and-modifiers

> I'm also wondering what face we're supposed to use for "receiver-less" method calls, such as calls to the methods defined in the same class, in e.g. Ruby and Java. Or C++/C#. They don't use ‘this’.

I don’t think emacs should worry about differentiating these cases. Highlight those tokens as tree-sitter sees them; regular function calls (i.e. `font-lock-function-call-face`). It’s a problem you cannot accurately solve without playing the compiler — with all of the implementation and not to mention performance baggage that comes with it.

> I also wonder whether we'll need to separate faces for properties: definitions vs. uses. That one we could use to do early, to keep the names uniform, e.g. we'd have:

This is something (also 3rd party package) lsp-mode supports through their semantic highlighting. They further distinguish between read and writes to variables. But again, they are able to do so because they hook directly into compilers.

Best regards,

Jacob Faibussowitsch
(Jacob Fai - booss - oh - vitch)

> On Feb 21, 2023, at 18:24, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> 
> On 21/02/2023 17:31, Jacob Faibussowitsch wrote:
> > but maybe a better default is to leave these faces totally blank and
> > just purely `:inherit` from `font-lock-function-name-face`
> 
> I believe so.
> 
>> +(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)
> 
> This one I was thinking of as well.
> 
>> +(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)
> 
> What's a "member function"? Is it like a method? If people want this distinction, we can add such face. But I'm curious whether some other editors use different colors for these cases.
> 
> I'm also wondering what face we're supposed to use for "receiver-less" method calls, such as calls to the methods defined in the same class, in e.g. Ruby and Java. Or C++/C#. They don't use 'this'.
> 
> I think more importantly, we need a new face for variables.
> 
> font-lock-variable-ref-face ?
> 
> I also wonder whether we'll need to separate faces for properties: definitions vs. uses. That one we could use to do early, to keep the names uniform, e.g. we'd have:
> 
>  font-lock-function-name-face
>  font-lock-function-call-face
>  font-lock-variable-name-face
>  font-lock-variable-ref-face
>  font-lock-property-name-face
>  font-lock-property-ref-face

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

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

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

On 22/02/2023 22:45, Yuan Fu wrote:
> 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.

An indirection seems like a separate new feature. Might be useful for 
some, but probably unnecessary for this discussion.

> 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.

The change itself should be very straightforward. If we agree on the set 
of faces (for variables and properties as well, right?), I don't mind 
posting a patch for review.

Whether it gets accepted or not.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Jacob Faibussowitsch <jacob.fai <at> gmail.com>
Cc: Randy Taylor <dev <at> rjt.dev>, Yuan Fu <casouri <at> gmail.com>,
 61655 <at> debbugs.gnu.org
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Wed, 22 Feb 2023 23:39:10 +0200

On 22/02/2023 20:07, Jacob Faibussowitsch wrote:
>> What's a "member function"? Is it like a method?
> Yeah, I suppose method is the more general term for it.
> 
>> If people want this distinction, we can add such face. But I'm curious whether some other editors use different colors for these cases.
> I personally do not; I brought it up because it was functionality that the 3rd party package had over stock. I think a good representative list is the one vscode offers:
> 
> https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide#standard-token-types-and-modifiers
> 
>> I'm also wondering what face we're supposed to use for "receiver-less" method calls, such as calls to the methods defined in the same class, in e.g. Ruby and Java. Or C++/C#. They don't use ‘this’.
> I don’t think emacs should worry about differentiating these cases. Highlight those tokens as tree-sitter sees them; regular function calls (i.e. `font-lock-function-call-face`). It’s a problem you cannot accurately solve without playing the compiler — with all of the implementation and not to mention performance baggage that comes with it.
> 
>> I also wonder whether we'll need to separate faces for properties: definitions vs. uses. That one we could use to do early, to keep the names uniform, e.g. we'd have:
> This is something (also 3rd party package) lsp-mode supports through their semantic highlighting. They further distinguish between read and writes to variables. But again, they are able to do so because they hook directly into compilers.

Thank you, then I guess we can skip that distinction, at least for now.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: casouri <at> gmail.com, 61655 <at> debbugs.gnu.org, jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Thu, 23 Feb 2023 20:15:04 +0200

> Cc: 61655 <at> debbugs.gnu.org
> Date: Wed, 22 Feb 2023 23:38:04 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 22/02/2023 22:45, Yuan Fu wrote:
> > 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.
> 
> An indirection seems like a separate new feature. Might be useful for 
> some, but probably unnecessary for this discussion.
> 
> > 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.
> 
> The change itself should be very straightforward. If we agree on the set 
> of faces (for variables and properties as well, right?), I don't mind 
> posting a patch for review.
> 
> Whether it gets accepted or not.

I'm okay with adding a few more faces to emacs-29, but please hurry,
as we don't have too much time for more additions.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Randy Taylor <dev <at> rjt.dev>, casouri <at> gmail.com,
 Theodor Thornhill <theo <at> thornhill.no>, 61655 <at> debbugs.gnu.org,
 jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Fri, 24 Feb 2023 04:31:08 +0200

[Message part 1 (text/plain, inline)]

On 23/02/2023 20:15, Eli Zaretskii wrote:
>> Cc:61655 <at> debbugs.gnu.org
>> Date: Wed, 22 Feb 2023 23:38:04 +0200
>> From: Dmitry Gutov<dgutov <at> yandex.ru>
>>
>> On 22/02/2023 22:45, Yuan Fu wrote:
>>> 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.
>> An indirection seems like a separate new feature. Might be useful for
>> some, but probably unnecessary for this discussion.
>>
>>> 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.
>> The change itself should be very straightforward. If we agree on the set
>> of faces (for variables and properties as well, right?), I don't mind
>> posting a patch for review.
>>
>> Whether it gets accepted or not.
> I'm okay with adding a few more faces to emacs-29, but please hurry,
> as we don't have too much time for more additions.

Here's the patch which adds the faces and their uses in all ts modes.

Comments welcome from all the interested parties. The patch is mostly 
straightforward, but there are some changes added as well, where it was 
needed to differentiate between declarations and references.

The important question here, I think, is whether we want to split 
font-lock-property-faces in two, like I did here.

By analogy with the other faces, I think it's going to be useful to 
differentiate between property definitions and property references. Not 
many of the languages modes used font-lock-property-face for 
property/attribute definitions, but some did.

[font-lock-more-finer-faces.diff (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: dev <at> rjt.dev, casouri <at> gmail.com, theo <at> thornhill.no, 61655 <at> debbugs.gnu.org,
 jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Fri, 24 Feb 2023 09:56:15 +0200

> Date: Fri, 24 Feb 2023 04:31:08 +0200
> Cc: casouri <at> gmail.com, 61655 <at> debbugs.gnu.org, jacob.fai <at> gmail.com,
>  Randy Taylor <dev <at> rjt.dev>, Theodor Thornhill <theo <at> thornhill.no>
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > I'm okay with adding a few more faces to emacs-29, but please hurry,
> > as we don't have too much time for more additions.
> 
> Here's the patch which adds the faces and their uses in all ts modes.

LGTM, thanks.

> The important question here, I think, is whether we want to split 
> font-lock-property-faces in two, like I did here.

What harm can it do, if done like you did, i.e. the faces are
indistinguishable by default?

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dev <at> rjt.dev, casouri <at> gmail.com, theo <at> thornhill.no, 61655 <at> debbugs.gnu.org,
 jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Fri, 24 Feb 2023 13:31:59 +0200

On 24/02/2023 09:56, Eli Zaretskii wrote:
>> The important question here, I think, is whether we want to split
>> font-lock-property-faces in two, like I did here.
> What harm can it do, if done like you did, i.e. the faces are
> indistinguishable by default?

Not much. We do rename the face this late into the pretest, though.

And if not many modes use it, then it could not be worth it. OTOH, modes 
sometimes need additional faces, to use for their unique syntactic 
elements. So more faces could be a good idea, just from that perspective.

So if nobody has objections, I'll install the patch later today.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: dev <at> rjt.dev, casouri <at> gmail.com, theo <at> thornhill.no, 61655 <at> debbugs.gnu.org,
 jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Fri, 24 Feb 2023 13:44:42 +0200

> Date: Fri, 24 Feb 2023 13:31:59 +0200
> Cc: dev <at> rjt.dev, casouri <at> gmail.com, theo <at> thornhill.no, 61655 <at> debbugs.gnu.org,
>  jacob.fai <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 24/02/2023 09:56, Eli Zaretskii wrote:
> >> The important question here, I think, is whether we want to split
> >> font-lock-property-faces in two, like I did here.
> > What harm can it do, if done like you did, i.e. the faces are
> > indistinguishable by default?
> 
> Not much. We do rename the face this late into the pretest, though.

That's fine: they were introduced just a few months ago.

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Eli Zaretskii <eliz <at> gnu.org>
Cc: dev <at> rjt.dev, casouri <at> gmail.com, 61655 <at> debbugs.gnu.org, jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Fri, 24 Feb 2023 15:24:14 +0100

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> On 24/02/2023 09:56, Eli Zaretskii wrote:
>>> The important question here, I think, is whether we want to split
>>> font-lock-property-faces in two, like I did here.
>> What harm can it do, if done like you did, i.e. the faces are
>> indistinguishable by default?
>
> Not much. We do rename the face this late into the pretest, though.
>
> And if not many modes use it, then it could not be worth it. OTOH, modes 
> sometimes need additional faces, to use for their unique syntactic 
> elements. So more faces could be a good idea, just from that perspective.
>
> So if nobody has objections, I'll install the patch later today.

No objections from me :)

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

From: Randy Taylor <dev <at> rjt.dev>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 61655 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Theodor Thornhill <theo <at> thornhill.no>, casouri <at> gmail.com, jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Sat, 25 Feb 2023 01:06:02 +0000

On Thursday, February 23rd, 2023 at 21:31, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> 
> On 23/02/2023 20:15, Eli Zaretskii wrote:
> 
> > > Cc:61655 <at> debbugs.gnu.org
> > > Date: Wed, 22 Feb 2023 23:38:04 +0200
> > > From: Dmitry Gutovdgutov <at> yandex.ru
> > > 
> > > On 22/02/2023 22:45, Yuan Fu wrote:
> > > 
> > > > 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.
> > > > An indirection seems like a separate new feature. Might be useful for
> > > > some, but probably unnecessary for this discussion.
> > > 
> > > > 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.
> > > > The change itself should be very straightforward. If we agree on the set
> > > > of faces (for variables and properties as well, right?), I don't mind
> > > > posting a patch for review.
> > > 
> > > Whether it gets accepted or not.
> > > I'm okay with adding a few more faces to emacs-29, but please hurry,
> > > as we don't have too much time for more additions.
> 
> 
> Here's the patch which adds the faces and their uses in all ts modes.
> 
> Comments welcome from all the interested parties. The patch is mostly
> straightforward, but there are some changes added as well, where it was
> needed to differentiate between declarations and references.
> 
> The important question here, I think, is whether we want to split
> font-lock-property-faces in two, like I did here.
> 
> By analogy with the other faces, I think it's going to be useful to
> differentiate between property definitions and property references. Not
> many of the languages modes used font-lock-property-face for
> property/attribute definitions, but some did.

I'm not sure about the naming of font-lock-variable-ref-face. It's confusing for languages that support actual references like C++ and Rust.

Maybe the opposite direction is better: font-lock-variable-def-face (or something similar) for definitions (or whatnot), and font-lock-variable-name-face to refer to uses (same goes for property). Or font-lock-variable-use-face. I don't know, naming is hard :).

Personally, I don't really see the value in differentiating these for variables. I can understand it a little more for properties. But I guess it doesn't hurt to add if folks want it.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Randy Taylor <dev <at> rjt.dev>
Cc: 61655 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Theodor Thornhill <theo <at> thornhill.no>, casouri <at> gmail.com, jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Sat, 25 Feb 2023 04:28:11 +0200

Hi Randy,

Thanks for the reply.

On 25/02/2023 03:06, Randy Taylor wrote:

>> Here's the patch which adds the faces and their uses in all ts modes.
>>
>> Comments welcome from all the interested parties. The patch is mostly
>> straightforward, but there are some changes added as well, where it was
>> needed to differentiate between declarations and references.
>>
>> The important question here, I think, is whether we want to split
>> font-lock-property-faces in two, like I did here.
>>
>> By analogy with the other faces, I think it's going to be useful to
>> differentiate between property definitions and property references. Not
>> many of the languages modes used font-lock-property-face for
>> property/attribute definitions, but some did.
> 
> I'm not sure about the naming of font-lock-variable-ref-face. It's confusing for languages that support actual references like C++ and Rust.

But even there "variable reference" is probably a suitable term for any 
occurrence of a variable other than its definition. While the references 
you're talking about are "value references".

> Maybe the opposite direction is better: font-lock-variable-def-face (or something similar) for definitions (or whatnot), and font-lock-variable-name-face to refer to uses (same goes for property). Or font-lock-variable-use-face. I don't know, naming is hard :).

I, uh, pushed the change before I noticed your email. ^^;

But perhaps we could refine, if there is enough support.

Indeed, I was slightly uneasy about the -ref- names, if only because 
they might seem a little cryptic. Using the name -def-face is something 
I thought about too, but it sounded a bit like the name of a macro.

A bigger problem, though, is that existing themes customize 
font-lock-variable-name-face. So we'd have to create inheritance the 
other way around (for the themes to continue working unchanged). Or we'd 
have to create face alias and use a yet different name for "variable 
references" (or "uses", or whatever we'd call them).

Inheritance "the other way around" would break the usage scenario 1 
below for users of existing themes. Or at least make it more difficult.

> Personally, I don't really see the value in differentiating these for variables. I can understand it a little more for properties. But I guess it doesn't hurt to add if folks want it.

I see two potential uses:

1. Customize treesit-font-lock-level to 4 but 
font-lock-variable-ref-face to copy 'default' (or close to it), to skip 
variable reference highlighting or make it less noticeable.

2. Pattern matching or comparably complex syntax which at a first glance 
may look like variable reference, but actually creates new bindings (or 
vice versa, creates new binding when one wanted to refer to an existing 
value).

Emphasizing the difference can help people, beginners especially [in a 
particular language].

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

From: Randy Taylor <dev <at> rjt.dev>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: casouri <at> gmail.com, 61655 <at> debbugs.gnu.org,
 Theodor Thornhill <theo <at> thornhill.no>, Eli Zaretskii <eliz <at> gnu.org>,
 jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Sat, 25 Feb 2023 03:59:46 +0000

On Friday, February 24th, 2023 at 21:28, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> Hi Randy,
> 
> Thanks for the reply.
> 
> On 25/02/2023 03:06, Randy Taylor wrote:
> 
> > > Here's the patch which adds the faces and their uses in all ts modes.
> > > 
> > > Comments welcome from all the interested parties. The patch is mostly
> > > straightforward, but there are some changes added as well, where it was
> > > needed to differentiate between declarations and references.
> > > 
> > > The important question here, I think, is whether we want to split
> > > font-lock-property-faces in two, like I did here.
> > > 
> > > By analogy with the other faces, I think it's going to be useful to
> > > differentiate between property definitions and property references. Not
> > > many of the languages modes used font-lock-property-face for
> > > property/attribute definitions, but some did.
> > 
> > I'm not sure about the naming of font-lock-variable-ref-face. It's confusing for languages that support actual references like C++ and Rust.
> 
> 
> But even there "variable reference" is probably a suitable term for any
> occurrence of a variable other than its definition. While the references
> you're talking about are "value references".

It is a suitable term, but there is a confusing overlap, at least to me. In C++ parlance, for example, they are referred to as reference variables. I wasn't really getting down to the semantics of it, just when I see something like:

void quack(int& thing)
                ^^^^^
obj_t& thing2 = otherthing;
       ^^^^^^

Those are the things I would expect font-lock-variable-ref-face to highlight if I was just going off of the name, and I would expect many others to think the same.

> 
> > Maybe the opposite direction is better: font-lock-variable-def-face (or something similar) for definitions (or whatnot), and font-lock-variable-name-face to refer to uses (same goes for property). Or font-lock-variable-use-face. I don't know, naming is hard :).
> 
> 
> I, uh, pushed the change before I noticed your email. ^^;
> 
> But perhaps we could refine, if there is enough support.
> 
> Indeed, I was slightly uneasy about the -ref- names, if only because
> they might seem a little cryptic. Using the name -def-face is something
> I thought about too, but it sounded a bit like the name of a macro.
> 
> A bigger problem, though, is that existing themes customize
> font-lock-variable-name-face. So we'd have to create inheritance the
> other way around (for the themes to continue working unchanged). Or we'd
> have to create face alias and use a yet different name for "variable
> references" (or "uses", or whatever we'd call them).
> 
> Inheritance "the other way around" would break the usage scenario 1
> below for users of existing themes. Or at least make it more difficult.

I don't have any better ideas than font-lock-{property,variable}-use-face, so I guess we can see if anyone else has any opinions on the matter.

> 
> > Personally, I don't really see the value in differentiating these for variables. I can understand it a little more for properties. But I guess it doesn't hurt to add if folks want it.
> 
> 
> I see two potential uses:
> 
> 1. Customize treesit-font-lock-level to 4 but
> font-lock-variable-ref-face to copy 'default' (or close to it), to skip
> variable reference highlighting or make it less noticeable.

Wouldn't they just remove the variable feature if they want that?

> 
> 2. Pattern matching or comparably complex syntax which at a first glance
> may look like variable reference, but actually creates new bindings (or
> vice versa, creates new binding when one wanted to refer to an existing
> value).
> 
> Emphasizing the difference can help people, beginners especially [in a
> particular language].
>

No doubt there are uses, I just don't really see them actually getting much use in practice. But maybe I'm wrong :).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Randy Taylor <dev <at> rjt.dev>
Cc: casouri <at> gmail.com, jacob.fai <at> gmail.com, theo <at> thornhill.no,
 61655 <at> debbugs.gnu.org, dgutov <at> yandex.ru
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Sat, 25 Feb 2023 10:05:58 +0200

> Date: Sat, 25 Feb 2023 01:06:02 +0000
> From: Randy Taylor <dev <at> rjt.dev>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, casouri <at> gmail.com, 61655 <at> debbugs.gnu.org, jacob.fai <at> gmail.com, Theodor Thornhill <theo <at> thornhill.no>
> 
> On Thursday, February 23rd, 2023 at 21:31, Dmitry Gutov <dgutov <at> yandex.ru> wrote:
> 
> I'm not sure about the naming of font-lock-variable-ref-face. It's confusing for languages that support actual references like C++ and Rust.

That's a different kind of "reference".

> Maybe the opposite direction is better: font-lock-variable-def-face (or something similar) for definitions (or whatnot), and font-lock-variable-name-face to refer to uses (same goes for property).

No, that would rename a widely used face which we had for many years.

>  Or font-lock-variable-use-face.

That could work, but then we'd need to change all the other "-ref-"
faces to "-use-" as well.

> Personally, I don't really see the value in differentiating these for variables. I can understand it a little more for properties. But I guess it doesn't hurt to add if folks want it.

Right, it doesn't hurt.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Randy Taylor <dev <at> rjt.dev>
Cc: casouri <at> gmail.com, 61655 <at> debbugs.gnu.org,
 Theodor Thornhill <theo <at> thornhill.no>, Eli Zaretskii <eliz <at> gnu.org>,
 jacob.fai <at> gmail.com
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Sat, 25 Feb 2023 15:05:38 +0200

On 25/02/2023 05:59, Randy Taylor wrote:

> It is a suitable term, but there is a confusing overlap, at least to me. In C++ parlance, for example, they are referred to as reference variables. I wasn't really getting down to the semantics of it, just when I see something like:
> 
> void quack(int& thing)
>                  ^^^^^
> obj_t& thing2 = otherthing;
>         ^^^^^^
> 
> Those are the things I would expect font-lock-variable-ref-face to highlight if I was just going off of the name, and I would expect many others to think the same.

That's not unreasonable.

> I don't have any better ideas than font-lock-{property,variable}-use-face, so I guess we can see if anyone else has any opinions on the matter.

The only one I could think of is 
font-lock-{property,variable}-value-face. But that one can give wrong 
ideas as well.

I suppose we should go with -use-, unless more alternatives are suggested.

>>> Personally, I don't really see the value in differentiating these for variables. I can understand it a little more for properties. But I guess it doesn't hurt to add if folks want it.
>>
>>
>> I see two potential uses:
>>
>> 1. Customize treesit-font-lock-level to 4 but
>> font-lock-variable-ref-face to copy 'default' (or close to it), to skip
>> variable reference highlighting or make it less noticeable.
> 
> Wouldn't they just remove the variable feature if they want that?

That's the obvious choice (which might be less accessible to those who 
don't venture into the manual, though, or don't write Elisp), but now 
they also have the option of toning down the highlights.

>> 2. Pattern matching or comparably complex syntax which at a first glance
>> may look like variable reference, but actually creates new bindings (or
>> vice versa, creates new binding when one wanted to refer to an existing
>> value).
>>
>> Emphasizing the difference can help people, beginners especially [in a
>> particular language].
>>
> 
> No doubt there are uses, I just don't really see them actually getting much use in practice. But maybe I'm wrong :).

We'll see. I hope we will. Some third-party theme or two might start 
carrying that distinction, to start with.

It might be nice to improve the default theme in that regard too, but 
that's a non-trivial task.

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Randy Taylor <dev <at> rjt.dev>
Cc: casouri <at> gmail.com, jacob.fai <at> gmail.com,
 Theodor Thornhill <theo <at> thornhill.no>, 61655-done <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#61655: [Tree sitter] [Feature Request] font-lock function
 calls, definitions, separately
Date: Tue, 28 Feb 2023 04:09:55 +0200

On 25/02/2023 15:05, Dmitry Gutov wrote:
> I suppose we should go with -use-, unless more alternatives are suggested.

And done. Thanks all!

Previous Next

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