bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Yuan Fu]

Hey Theo and Jostein,

As the complete feature freeze approaching, I think it’s a good time to
standardize the font-lock features. Below is the change I would make to
csharp-ts-mode:

- take string_interpolation out of string
- add function, variable feature
- change attribute to property
- expression is not in the list, no harm to keep it
  around, of course
- maybe add assignment feature

Feel free to correct me if I misunderstood anything. TIA!

Below is the list of standard features, for your reference:

Basic tokens:

delimiter       ,.;      (delimit things)
operator        == != || (produces a value)
bracket         []{}()
misc-punctuation  anything else

constant        true, false, null
number
keyword
comment         (includes doc-comments)
string          (includes chars and docstrings)
string-interpolation    f"text {variable}"
escape-sequence         "\n\t\\"
function                every function identifier
variable                every variable identifier
type                    every type identifier
property                a.b  <--- highlight b
key                     { a: b, c: d } <--- highlight a, c
error                   highlight parse error

Abstract features:

assignment: the LHS of an assignment (thing being assigned to), eg:

a = b    <--- highlight a
a.b = c  <--- highlight b
a[1] = d <--- highlight a

definition: the thing being defined, eg:

int a(int b) { <--- highlight a
return 0
}

int a;  <-- highlight a

struct a { <--- highlight a
int b;   <--- highlight b
}

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Yuan Fu]

I probably didn’t get the X-Debbugs-CC thing right, CC’ing Theo and
Jostein manually :-)

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 4342 bytes --]

Hey Yuan.

Thanks for the heads up!

To be quite honest, that's quite a lot of stuff in such a "little" bug, 
so if it's OK, I think we should start on the top and work our way down.

So a "complete feature freeze" is approaching. That makes complete 
sense, and I respect that. Are there any exact deadlines or dates we'd 
like to stay ahead of, or is this more an abstract thing, until Emacs 29 
is eventually deemed ready for release?

While standardizing font-lock features is probably a good thing, at the 
end of the day, it does mean changing working code. In that regard, I'd 
like to ensure we don't change more than we need to, to not impose any 
unneeded risk near the feature freeze and eventual Emacs 29 release. 
Basically, whatever objections I may have, please assume them to be in 
good faith.

As far as standardizing the features, which bar are we standardizing 
them against, or along with? Are other modes getting standardized as 
well? In case, which?

To take a personal nitpick as an example... python-ts-mode does not even 
highlight function-invocations, despite me having sent in patches to fix 
that[1]? How does that play into this standardization? I can't say I've 
seen much response to my bug-report or patch so far, and I mean... We 
can't standardize features which are not yet even implemented, right? In 
which case, I feel some issues should take precedence over others.

I'm not trying to be difficult or anything, but whenever I hear about 
standardization, I feel these are important questions to ask. Left 
unresolved they can often leads to disenfranchising people from their 
own works, if they are left feeling like they are forced to make changes 
they disagree with or dont see the benefits of.

I really think this "small" part could definitely use a little more 
details. What's our grand plan? How many major-modes does it involve? 
And last how much time do we have? Basically: is the overall plan 
realistic within the timelines we have?

So before moving into details about csharp-ts-mode specifically, I'd 
love to see at least some links to the discussion space where the 
overall standardization has been discussed.

For the time being, or for now at least, I would be against any 
standardization-related changes taking place in csharp-ts-mode until 
I've seen such a discussion and been able to raise my voice about any 
concerns I may have there, if any.

Does that make sense? Or does that seem unreasonable or entitled of me?


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=59977


Kind regards
*Jostein Kjønigsen*

jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjønigsen.no <https://jostein.kjønigsen.no>
On 29.12.2022 20:55, Yuan Fu wrote:
> I probably didn’t get the X-Debbugs-CC thing right, CC’ing Theo and
> Jostein manually :-)

Hey Theo and Jostein,

As the complete feature freeze approaching, I think it’s a good time to
standardize the font-lock features. Below is the change I would make to
csharp-ts-mode:

- take string_interpolation out of string
- add function, variable feature
- change attribute to property
- expression is not in the list, no harm to keep it
   around, of course
- maybe add assignment feature

Feel free to correct me if I misunderstood anything. TIA!

Below is the list of standard features, for your reference:

Basic tokens:

delimiter       ,.;      (delimit things)
operator        == != || (produces a value)
bracket         []{}()
misc-punctuation  anything else

constant        true, false, null
number
keyword
comment         (includes doc-comments)
string          (includes chars and docstrings)
string-interpolation    f"text {variable}"
escape-sequence         "\n\t\\"
function                every function identifier
variable                every variable identifier
type                    every type identifier
property                a.b  <--- highlight b
key                     { a: b, c: d } <--- highlight a, c
error                   highlight parse error

Abstract features:

assignment: the LHS of an assignment (thing being assigned to), eg:

a = b    <--- highlight a
a.b = c  <--- highlight b
a[1] = d <--- highlight a

definition: the thing being defined, eg:

int a(int b) { <--- highlight a
return 0
}

int a;  <-- highlight a

struct a { <--- highlight a
int b;   <--- highlight b
}

[-- Attachment #2: Type: text/html, Size: 6823 bytes --]

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Eli Zaretskii]

> Cc: Theodor Thornhill <theo@thornhill.no>
> Date: Thu, 29 Dec 2022 22:03:06 +0100
> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> 
> While standardizing font-lock features is probably a good thing, at the end of the day, it does mean changing
> working code. In that regard, I'd like to ensure we don't change more than we need to, to not impose any
> unneeded risk near the feature freeze and eventual Emacs 29 release. Basically, whatever objections I may
> have, please assume them to be in good faith.
> 
> As far as standardizing the features, which bar are we standardizing them against, or along with? Are other
> modes getting standardized as well? In case, which?
> 
> To take a personal nitpick as an example... python-ts-mode does not even highlight function-invocations,
> despite me having sent in patches to fix that[1]? How does that play into this standardization? I can't say I've
> seen much response to my bug-report or patch so far, and I mean... We can't standardize features which
> are not yet even implemented, right? In which case, I feel some issues should take precedence over others.
> 
> I'm not trying to be difficult or anything, but whenever I hear about standardization, I feel these are important
> questions to ask. Left unresolved they can often leads to disenfranchising people from their own works, if
> they are left feeling like they are forced to make changes they disagree with or dont see the benefits of.

This is eventually up to you.  You can always go with what your gut
feeling is about what's TRT, and correct that later if necessary,
given the user feedback and maintenance experience we collect.

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Yuan Fu]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> Hey Yuan.
>
> Thanks for the heads up!
>
> To be quite honest, that's quite a lot of stuff in such a "little" bug, so if it's OK, I think we should start on the top and work
> our way down.
>
> So a "complete feature freeze" is approaching. That makes complete sense, and I respect that. Are there any exact
> deadlines or dates we'd like to stay ahead of, or is this more an abstract thing, until Emacs 29 is eventually deemed ready
> for release?

I heard that it’s in a few days (from Eli). I believe the idea is that
no more new features could be added to emacs-29 branch, only bug fixes.
This actually should’ve happened when emacs-29 was cut, but tree-sitter
features had an exemption because it was merged relatively late.

> While standardizing font-lock features is probably a good thing, at the end of the day, it does mean changing working
> code. In that regard, I'd like to ensure we don't change more than we need to, to not impose any unneeded risk near the
> feature freeze and eventual Emacs 29 release. Basically, whatever objections I may have, please assume them to be in
> good faith.
>
> As far as standardizing the features, which bar are we standardizing them against, or along with? Are other modes
> getting standardized as well? In case, which?

I’m working on python and javascript. Newer modes I think more or less
follows the "standard list" since they are created after the discussion
of that list.

> To take a personal nitpick as an example... python-ts-mode does not even highlight function-invocations, despite me
> having sent in patches to fix that[1]? How does that play into this standardization? I can't say I've seen much response to
> my bug-report or patch so far, and I mean... We can't standardize features which are not yet even implemented, right? In
> which case, I feel some issues should take precedence over others.

I applied your patch, with some modification (so it aligns with the
standard list). Looking at the bug report, I must’ve forgot to reply to
you after I made the change. That’s my fault.

> I'm not trying to be difficult or anything, but whenever I hear about standardization, I feel these are important questions
> to ask. Left unresolved they can often leads to disenfranchising people from their own works, if they are left feeling like
> they are forced to make changes they disagree with or dont see the benefits of.
>
> I really think this "small" part could definitely use a little more
> details. What's our grand plan?

To make features of each tree-sitter major mode more consistent. We
wouldn’t want features that has the same name but different meaning, or
features of the same meaning but different name.

> How many major-modes does it involve?

Ideally all the built-in major modes.

> And last how much time do we have? Basically: is the overall plan realistic within the timelines we have?

I’m merely suggesting potential improvements to csharp-ts-mode.  As the
maintainer of it, whether it is possible or desirable to make the
changes will be your call ;-)

> So before moving into details about csharp-ts-mode specifically, I'd love to see at least some links to the discussion space
> where the overall standardization has been discussed.

The initial discussion happened on here:

https://lists.gnu.org/archive/html/emacs-devel/2022-11/msg01544.html

I just posted a general call to standardize major mode font-lock
features, which stirred up a new discussion about the standard list (as
discussion on mailing lists go :-), it started at here:

https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01202.html

Maybe I should CC people that would be interested in such discussion.

> For the time being, or for now at least, I would be against any standardization-related changes taking place in
> csharp-ts-mode until I've seen such a discussion and been able to raise my voice about any concerns I may have there, if
> any.
>
> Does that make sense? Or does that seem unreasonable or entitled of me?

Your doubts are completely reasonable. As I said, you are the maintainer
of csharp-mode.el, not me, so you can regard my words as a suggestion
rather than request. (Or perhaps nice suggestive request ;-)

Yuan

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Eli Zaretskii]

> Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
> From: Yuan Fu <casouri@gmail.com>
> Date: Thu, 29 Dec 2022 14:16:13 -0800
> 
> > So a "complete feature freeze" is approaching. That makes complete sense, and I respect that. Are there any exact
> > deadlines or dates we'd like to stay ahead of, or is this more an abstract thing, until Emacs 29 is eventually deemed ready
> > for release?
> 
> I heard that it’s in a few days (from Eli).

That was a few days ago ;-)  So now it's "any day now".

> I believe the idea is that no more new features could be added to
> emacs-29 branch, only bug fixes.  This actually should’ve happened
> when emacs-29 was cut, but tree-sitter features had an exemption
> because it was merged relatively late.

Yes.

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
>> From: Yuan Fu <casouri@gmail.com>
>> Date: Thu, 29 Dec 2022 14:16:13 -0800
>>
>>> So a "complete feature freeze" is approaching. That makes complete sense, and I respect that. Are there any exact
>>> deadlines or dates we'd like to stay ahead of, or is this more an abstract thing, until Emacs 29 is eventually deemed ready
>>> for release?
>> I heard that it’s in a few days (from Eli).
> That was a few days ago ;-)  So now it's "any day now".

Ok. That's unfortunate timing.

To be clear, I think it's absolutely realistic to get csharp-ts-mode to 
adhere to some of the guidelines outlined in the 
tree-sitter-standardization thread.

But it's completely unrealistic (at least on my part) to get any 
well-crafted and well-tested changes into csharp-ts-mode until after 
new-years.

Maybe Theo has time for this?

--
Jostein

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Eli Zaretskii]

> Date: Fri, 30 Dec 2022 14:35:46 +0100
> Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> 
> Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
> >> From: Yuan Fu <casouri@gmail.com>
> >> Date: Thu, 29 Dec 2022 14:16:13 -0800
> >>
> >>> So a "complete feature freeze" is approaching. That makes complete sense, and I respect that. Are there any exact
> >>> deadlines or dates we'd like to stay ahead of, or is this more an abstract thing, until Emacs 29 is eventually deemed ready
> >>> for release?
> >> I heard that it’s in a few days (from Eli).
> > That was a few days ago ;-)  So now it's "any day now".
> 
> Ok. That's unfortunate timing.
> 
> To be clear, I think it's absolutely realistic to get csharp-ts-mode to 
> adhere to some of the guidelines outlined in the 
> tree-sitter-standardization thread.
> 
> But it's completely unrealistic (at least on my part) to get any 
> well-crafted and well-tested changes into csharp-ts-mode until after 
> new-years.

If you can come up with a 85% correct code soon, and leave the rest
for bug-fixing, that's also acceptable.

Otherwise, please understand my POV: we do want to release Emacs 29
soon.  The tree-sitter related features already got a full month of
slack, whereby new features were acceptable on the release branch.  If
we keep delaying the freeze, we will not release Emacs 29 any time
soon.  You have all been here for the past month, and I announced the
rules loud and clear, so if some modes are still not up to speed with
the latest treesit.el changes, then it's too bad, but we will have to
wait for Emacs 30 with those.  I'm sorry, but we do need to draw the
line in the sand at some point: people are waiting for Emacs 29, and
we cannot disappoint them.

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

On 30.12.2022 15:15, Eli Zaretskii wrote:
>> Ok. That's unfortunate timing.
>> To be clear, I think it's absolutely realistic to get csharp-ts-mode to
>> adhere to some of the guidelines outlined in the
>> tree-sitter-standardization thread.
>>
>> But it's completely unrealistic (at least on my part) to get any
>> well-crafted and well-tested changes into csharp-ts-mode until after
>> new-years.
> If you can come up with a 85% correct code soon, and leave the rest
> for bug-fixing, that's also acceptable.
>
> Otherwise, please understand my POV: we do want to release Emacs 29
> soon.  The tree-sitter related features already got a full month of
> slack, whereby new features were acceptable on the release branch.  If
> we keep delaying the freeze, we will not release Emacs 29 any time
> soon.  You have all been here for the past month, and I announced the
> rules loud and clear, so if some modes are still not up to speed with
> the latest treesit.el changes, then it's too bad, but we will have to
> wait for Emacs 30 with those.  I'm sorry, but we do need to draw the
> line in the sand at some point: people are waiting for Emacs 29, and
> we cannot disappoint them.

I completely understand.

I've left some thoughts about the standardization-process -in general- 
in the Emacs-devel thread, on how we should "cope" with exactly that 
situation.

To be clear: I think csharp-ts-mode works well beyond 85% (it's what I 
use as my daily driver), but the syntax-highlighting at level 3 may be 
more excessive than some people (like Stefan) prefer.

If we instead for these "major" changes suggested by Yuan, instead aim 
for just moving some "smaller" implementation-detail 
(function-invocations and property-highlighting) to level 4, I think we 
she be able to get something which is mostly what Stefan would expect 
and prefer, and it would be a much smaller change.

Then we can take a look at those bigger changes (standardized features, 
enabling/disabling them individually, as end-users, etc) for Emacs-30.

I think that's a more realistic plan. Does that sound OK?

--
Jostein

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Eli Zaretskii]

> Date: Fri, 30 Dec 2022 15:39:20 +0100
> Cc: casouri@gmail.com, 60376@debbugs.gnu.org, theo@thornhill.no
> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
> 
> To be clear: I think csharp-ts-mode works well beyond 85% (it's what I 
> use as my daily driver), but the syntax-highlighting at level 3 may be 
> more excessive than some people (like Stefan) prefer.
> 
> If we instead for these "major" changes suggested by Yuan, instead aim 
> for just moving some "smaller" implementation-detail 
> (function-invocations and property-highlighting) to level 4, I think we 
> she be able to get something which is mostly what Stefan would expect 
> and prefer, and it would be a much smaller change.
> 
> Then we can take a look at those bigger changes (standardized features, 
> enabling/disabling them individually, as end-users, etc) for Emacs-30.
> 
> I think that's a more realistic plan. Does that sound OK?

Yes, it does.  And I urge you to submit patches to that effect.

Thanks.

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> 
>> 
>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>> Cc: casouri@gmail.com, 60376@debbugs.gnu.org, theo@thornhill.no
>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>> 
>> To be clear: I think csharp-ts-mode works well beyond 85% (it's what I 
>> use as my daily driver), but the syntax-highlighting at level 3 may be 
>> more excessive than some people (like Stefan) prefer.
>> 
>> If we instead for these "major" changes suggested by Yuan, instead aim 
>> for just moving some "smaller" implementation-detail 
>> (function-invocations and property-highlighting) to level 4, I think we 
>> she be able to get something which is mostly what Stefan would expect 
>> and prefer, and it would be a much smaller change.
>> 
>> Then we can take a look at those bigger changes (standardized features, 
>> enabling/disabling them individually, as end-users, etc) for Emacs-30.
>> 
>> I think that's a more realistic plan. Does that sound OK?
> 
> Yes, it does.  And I urge you to submit patches to that effect.
> 
> Thanks.

Theo has offered to come up with some patches and I’ll do my best to battle-test them. 

Hopefully we can get this done quickly enough to suit your taste ;)

—
Jostein

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz@gnu.org> wrote:
>> 
>> 
>>> 
>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>> Cc: casouri@gmail.com, 60376@debbugs.gnu.org, theo@thornhill.no
>>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>>> 
>>> To be clear: I think csharp-ts-mode works well beyond 85% (it's what I 
>>> use as my daily driver), but the syntax-highlighting at level 3 may be 
>>> more excessive than some people (like Stefan) prefer.
>>> 
>>> If we instead for these "major" changes suggested by Yuan, instead aim 
>>> for just moving some "smaller" implementation-detail 
>>> (function-invocations and property-highlighting) to level 4, I think we 
>>> she be able to get something which is mostly what Stefan would expect 
>>> and prefer, and it would be a much smaller change.
>>> 
>>> Then we can take a look at those bigger changes (standardized features, 
>>> enabling/disabling them individually, as end-users, etc) for Emacs-30.
>>> 
>>> I think that's a more realistic plan. Does that sound OK?
>> 
>> Yes, it does.  And I urge you to submit patches to that effect.
>> 
>> Thanks.
>
> Theo has offered to come up with some patches and I’ll do my best to battle-test them. 
>
> Hopefully we can get this done quickly enough to suit your taste ;)
>

Let's start here!

If you're satisfied, Jostein, report back, then you install, Yuan?

Then rinse repeat :-)

Theo


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Tweak-csharp-mode-font-lock-settings.patch --]
[-- Type: text/x-diff, Size: 4823 bytes --]

From 36ba718d0f4c528b7518da33d9c4e591f578ab10 Mon Sep 17 00:00:00 2001
From: Theodor Thornhill <theo@thornhill.no>
Date: Fri, 30 Dec 2022 20:26:09 +0100
Subject: [PATCH] Tweak csharp-mode font-lock-settings

* lisp/progmodes/csharp-mode.el (csharp-ts-mode--font-lock-settings):
Rearrange features.
(csharp-ts-mode): Rearrange features.
---
 lisp/progmodes/csharp-mode.el | 53 +++++++++++++++++++++--------------
 1 file changed, 32 insertions(+), 21 deletions(-)

diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index 66e4a65184..bd0e023db1 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -692,25 +692,47 @@ csharp-ts-mode--keywords
 
 (defvar csharp-ts-mode--font-lock-settings
   (treesit-font-lock-rules
+   :language 'c-sharp
+   :feature 'expression
+   '((conditional_expression (identifier) @font-lock-variable-name-face)
+     (postfix_unary_expression (identifier)* @font-lock-variable-name-face)
+     (assignment_expression (identifier) @font-lock-variable-name-face))
+
+   :language 'c-sharp
+   :feature 'bracket
+   '((["(" ")" "[" "]" "{" "}"]) @font-lock-bracket-face)
+
+   :language 'c-sharp
+   :feature 'delimiter
+   '((["," ":" ";"]) @font-lock-delimiter-face)
+
+   :language 'c-sharp
+   :feature 'error
+   '((ERROR) @font-lock-warning-face)
+
    :language 'c-sharp
    :override t
    :feature 'comment
-   '((comment)  @font-lock-comment-face)
+   '((comment) @font-lock-comment-face)
+
    :language 'c-sharp
    :override t
    :feature 'keyword
    `([,@csharp-ts-mode--keywords] @font-lock-keyword-face
      (modifier) @font-lock-keyword-face
      (this_expression) @font-lock-keyword-face)
+
    :language 'c-sharp
    :override t
-   :feature 'attribute
+   :feature 'property
    `((attribute (identifier) @font-lock-property-face (attribute_argument_list))
      (attribute (identifier) @font-lock-property-face))
+
    :language 'c-sharp
    :override t
    :feature 'escape-sequence
    '((escape_sequence) @font-lock-escape-face)
+
    :language 'c-sharp
    :override t
    :feature 'literal
@@ -718,6 +740,7 @@ csharp-ts-mode--font-lock-settings
      (real_literal) @font-lock-number-face
      (null_literal) @font-lock-constant-face
      (boolean_literal) @font-lock-constant-face)
+
    :language 'c-sharp
    :override t
    :feature 'string
@@ -730,6 +753,7 @@ csharp-ts-mode--font-lock-settings
       "$\""
       "@$\""
       "$@\""] @font-lock-string-face)
+
    :language 'c-sharp
    :override t
    :feature 'type
@@ -750,14 +774,14 @@ csharp-ts-mode--font-lock-settings
       target: (identifier) @font-lock-type-face)
      (type_of_expression (identifier) @font-lock-type-face)
      (object_creation_expression (identifier) @font-lock-type-face))
+
    :language 'c-sharp
    :feature 'definition
    :override t
    '((qualified_name (identifier) @font-lock-type-face)
      (using_directive (identifier) @font-lock-type-face)
      (using_directive (name_equals
-                       (identifier) @font-lock-type-face
-                       ["="] @default-face))
+                       (identifier) @font-lock-type-face))
 
      (enum_declaration (identifier) @font-lock-type-face)
      (enum_member_declaration (identifier) @font-lock-variable-name-face)
@@ -820,24 +844,11 @@ csharp-ts-mode--font-lock-settings
 
      (binary_expression (identifier) @font-lock-variable-name-face)
      (argument (identifier) @font-lock-variable-name-face))
-   :language 'c-sharp
-   :feature 'expression
-   '((conditional_expression (identifier) @font-lock-variable-name-face)
-     (postfix_unary_expression (identifier)* @font-lock-variable-name-face)
-     (assignment_expression (identifier) @font-lock-variable-name-face))
-   :language 'c-sharp
-   :feature 'bracket
-   '((["(" ")" "[" "]" "{" "}"]) @font-lock-bracket-face)
-
-   :language 'c-sharp
-   :feature 'delimiter
-   '((["," ":" ";"]) @font-lock-delimiter-face)
 
    :language 'c-sharp
    :feature 'escape-sequence
    :override t
-   '((escape_sequence) @font-lock-escape-face
-     (ERROR) @font-lock-warning-face)))
+   '((escape_sequence) @font-lock-escape-face)))
 
 ;;;###autoload
 (add-to-list 'auto-mode-alist '("\\.cs\\'" . csharp-mode))
@@ -903,9 +914,9 @@ csharp-ts-mode
   (setq-local treesit-font-lock-settings csharp-ts-mode--font-lock-settings)
   (setq-local treesit-font-lock-feature-list
               '(( comment definition)
-                ( keyword string escape-sequence type)
-                ( attribute constant expression literal)
-                ( bracket delimiter)))
+                ( keyword string type)
+                ( constant escape-sequence expression literal property)
+                ( bracket delimiter error)))
 
   ;; Imenu.
   (setq-local treesit-simple-imenu-settings
-- 
2.34.1

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

On 30.12.2022 20:30, Theodor Thornhill wrote:
> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
>
>>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz@gnu.org> wrote:
>>>
>>> 
>>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>>> Cc: casouri@gmail.com, 60376@debbugs.gnu.org, theo@thornhill.no
>>>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>>>>
>>>> To be clear: I think csharp-ts-mode works well beyond 85% (it's what I
>>>> use as my daily driver), but the syntax-highlighting at level 3 may be
>>>> more excessive than some people (like Stefan) prefer.
>>>>
>>>> If we instead for these "major" changes suggested by Yuan, instead aim
>>>> for just moving some "smaller" implementation-detail
>>>> (function-invocations and property-highlighting) to level 4, I think we
>>>> she be able to get something which is mostly what Stefan would expect
>>>> and prefer, and it would be a much smaller change.
>>>>
>>>> Then we can take a look at those bigger changes (standardized features,
>>>> enabling/disabling them individually, as end-users, etc) for Emacs-30.
>>>>
>>>> I think that's a more realistic plan. Does that sound OK?
>>> Yes, it does.  And I urge you to submit patches to that effect.
>>>
>>> Thanks.
>> Theo has offered to come up with some patches and I’ll do my best to battle-test them.
>>
>> Hopefully we can get this done quickly enough to suit your taste ;)
>>
> Let's start here!
>
> If you're satisfied, Jostein, report back, then you install, Yuan?
>
> Then rinse repeat :-)
>
> Theo

I've tested it, and I can't say I see any regressions.

Two things though:

- Method-invocations are still getting fontified on level 3. I believe 
Stefan wanted this to be on level 4?

- I see we've missed fontification of method-invocations on self-methods 
(this.DoSomething()) entirely.

If we fix the first thing, I guess the second one is also doable? :)

--
Jostein

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 31 December 2022 10:53:54 CET, "Jostein Kjønigsen" <jostein@secure.kjonigsen.net> wrote:
>On 30.12.2022 20:30, Theodor Thornhill wrote:
>> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
>> 
>>>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz@gnu.org> wrote:
>>>> 
>>>> 
>>>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>>>> Cc: casouri@gmail.com, 60376@debbugs.gnu.org, theo@thornhill.no
>>>>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>>>>> 
>>>>> To be clear: I think csharp-ts-mode works well beyond 85% (it's what I
>>>>> use as my daily driver), but the syntax-highlighting at level 3 may be
>>>>> more excessive than some people (like Stefan) prefer.
>>>>> 
>>>>> If we instead for these "major" changes suggested by Yuan, instead aim
>>>>> for just moving some "smaller" implementation-detail
>>>>> (function-invocations and property-highlighting) to level 4, I think we
>>>>> she be able to get something which is mostly what Stefan would expect
>>>>> and prefer, and it would be a much smaller change.
>>>>> 
>>>>> Then we can take a look at those bigger changes (standardized features,
>>>>> enabling/disabling them individually, as end-users, etc) for Emacs-30.
>>>>> 
>>>>> I think that's a more realistic plan. Does that sound OK?
>>>> Yes, it does.  And I urge you to submit patches to that effect.
>>>> 
>>>> Thanks.
>>> Theo has offered to come up with some patches and I’ll do my best to battle-test them.
>>> 
>>> Hopefully we can get this done quickly enough to suit your taste ;)
>>> 
>> Let's start here!
>> 
>> If you're satisfied, Jostein, report back, then you install, Yuan?
>> 
>> Then rinse repeat :-)
>> 
>> Theo
>
>I've tested it, and I can't say I see any regressions.
>
>Two things though:
>
>- Method-invocations are still getting fontified on level 3. I believe Stefan wanted this to be on level 4?
>
>- I see we've missed fontification of method-invocations on self-methods (this.DoSomething()) entirely.
>
>If we fix the first thing, I guess the second one is also doable? :)
>
>--
>Jostein
>

Great! Yuan or Eli, will you install? I'll follow up with more stuff later :)

Theo

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 30 December 2022 15:15:48 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 30 Dec 2022 14:35:46 +0100
>> Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>> 
>> Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
>> >> From: Yuan Fu <casouri@gmail.com>
>> >> Date: Thu, 29 Dec 2022 14:16:13 -0800
>> >>
>> >>> So a "complete feature freeze" is approaching. That makes complete sense, and I respect that. Are there any exact
>> >>> deadlines or dates we'd like to stay ahead of, or is this more an abstract thing, until Emacs 29 is eventually deemed ready
>> >>> for release?
>> >> I heard that it’s in a few days (from Eli).
>> > That was a few days ago ;-)  So now it's "any day now".
>> 
>> Ok. That's unfortunate timing.
>> 
>> To be clear, I think it's absolutely realistic to get csharp-ts-mode to 
>> adhere to some of the guidelines outlined in the 
>> tree-sitter-standardization thread.
>> 
>> But it's completely unrealistic (at least on my part) to get any 
>> well-crafted and well-tested changes into csharp-ts-mode until after 
>> new-years.
>
>If you can come up with a 85% correct code soon, and leave the rest
>for bug-fixing, that's also acceptable.
>
>Otherwise, please understand my POV: we do want to release Emacs 29
>soon.  The tree-sitter related features already got a full month of
>slack, whereby new features were acceptable on the release branch.  If
>we keep delaying the freeze, we will not release Emacs 29 any time
>soon.  You have all been here for the past month, and I announced the
>rules loud and clear, so if some modes are still not up to speed with
>the latest treesit.el changes, then it's too bad, but we will have to
>wait for Emacs 30 with those.  I'm sorry, but we do need to draw the
>line in the sand at some point: people are waiting for Emacs 29, and
>we cannot disappoint them.

I agree, but I'll see what I can do this evening. 

Jostein, if you can take the patch I concoct for a spin I'm sure we can reach that 85% mark ;)

Theo

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

> On 30 Dec 2022, at 15:42, Theodor Thornhill <theo@thornhill.no> wrote:
> 
> 
> 
> On 30 December 2022 15:15:48 CET, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Fri, 30 Dec 2022 14:35:46 +0100
>>> Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
>>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>>> 
>>> Cc: 60376@debbugs.gnu.org, jostein@kjonigsen.net, theo@thornhill.no
>>>>> From: Yuan Fu <casouri@gmail.com>
>>>>> Date: Thu, 29 Dec 2022 14:16:13 -0800
>>>>> 
>>>>>> So a "complete feature freeze" is approaching. That makes complete sense, and I respect that. Are there any exact
>>>>>> deadlines or dates we'd like to stay ahead of, or is this more an abstract thing, until Emacs 29 is eventually deemed ready
>>>>>> for release?
>>>>> I heard that it’s in a few days (from Eli).
>>>> That was a few days ago ;-)  So now it's "any day now".
>>> 
>>> Ok. That's unfortunate timing.
>>> 
>>> To be clear, I think it's absolutely realistic to get csharp-ts-mode to 
>>> adhere to some of the guidelines outlined in the 
>>> tree-sitter-standardization thread.
>>> 
>>> But it's completely unrealistic (at least on my part) to get any 
>>> well-crafted and well-tested changes into csharp-ts-mode until after 
>>> new-years.
>> 
>> If you can come up with a 85% correct code soon, and leave the rest
>> for bug-fixing, that's also acceptable.
>> 
>> Otherwise, please understand my POV: we do want to release Emacs 29
>> soon.  The tree-sitter related features already got a full month of
>> slack, whereby new features were acceptable on the release branch.  If
>> we keep delaying the freeze, we will not release Emacs 29 any time
>> soon.  You have all been here for the past month, and I announced the
>> rules loud and clear, so if some modes are still not up to speed with
>> the latest treesit.el changes, then it's too bad, but we will have to
>> wait for Emacs 30 with those.  I'm sorry, but we do need to draw the
>> line in the sand at some point: people are waiting for Emacs 29, and
>> we cannot disappoint them.
> 
> I agree, but I'll see what I can do this evening. 
> 
> Jostein, if you can take the patch I concoct for a spin I'm sure we can reach that 85% mark ;)
> 
> Theo

Sounds good. Sure thing!

—
Jostein

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Yuan Fu]

Theodor Thornhill <theo@thornhill.no> writes:

> On 31 December 2022 10:53:54 CET, "Jostein Kjønigsen" <jostein@secure.kjonigsen.net> wrote:
>>On 30.12.2022 20:30, Theodor Thornhill wrote:
>>> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
>>> 
>>>>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>> 
>>>>> 
>>>>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>>>>> Cc: casouri@gmail.com, 60376@debbugs.gnu.org, theo@thornhill.no
>>>>>> From: Jostein Kjønigsen <jostein@secure.kjonigsen.net>
>>>>>> 
>>>>>> To be clear: I think csharp-ts-mode works well beyond 85% (it's what I
>>>>>> use as my daily driver), but the syntax-highlighting at level 3 may be
>>>>>> more excessive than some people (like Stefan) prefer.
>>>>>> 
>>>>>> If we instead for these "major" changes suggested by Yuan, instead aim
>>>>>> for just moving some "smaller" implementation-detail
>>>>>> (function-invocations and property-highlighting) to level 4, I think we
>>>>>> she be able to get something which is mostly what Stefan would expect
>>>>>> and prefer, and it would be a much smaller change.
>>>>>> 
>>>>>> Then we can take a look at those bigger changes (standardized features,
>>>>>> enabling/disabling them individually, as end-users, etc) for Emacs-30.
>>>>>> 
>>>>>> I think that's a more realistic plan. Does that sound OK?
>>>>> Yes, it does.  And I urge you to submit patches to that effect.
>>>>> 
>>>>> Thanks.
>>>> Theo has offered to come up with some patches and I’ll do my best to battle-test them.
>>>> 
>>>> Hopefully we can get this done quickly enough to suit your taste ;)
>>>> 
>>> Let's start here!
>>> 
>>> If you're satisfied, Jostein, report back, then you install, Yuan?
>>> 
>>> Then rinse repeat :-)
>>> 
>>> Theo
>>
>>I've tested it, and I can't say I see any regressions.
>>
>>Two things though:
>>
>>- Method-invocations are still getting fontified on level 3. I believe Stefan wanted this to be on level 4?
>>
>>- I see we've missed fontification of method-invocations on self-methods (this.DoSomething()) entirely.
>>
>>If we fix the first thing, I guess the second one is also doable? :)
>>
>>--
>>Jostein
>>
>
> Great! Yuan or Eli, will you install? I'll follow up with more stuff later :)
>
> Theo

I applied it, thanks!

Yuan

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 298 bytes --]

On 31.12.2022 23:21, Yuan Fu wrote:
> I applied it, thanks!
>
> Yuan

Following up this case, attached is a patch which from what I can tell 
movies function invocation fontification to level 4, without any other 
regressions.

Theo: Care to take it for a spin? Does it look OK by you?

--
Jostein

[-- Attachment #2: 0001-lisp-progmodes-csharp-mode.el-adjust-function-call-f.patch --]
[-- Type: text/x-patch, Size: 2999 bytes --]

From bdb70bba35aa1fe36f5bb66e880289cfcfe3b339 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jostein=20Kj=C3=B8nigsen?= <jostein@kjonigsen.net>
Date: Sun, 1 Jan 2023 17:27:06 +0100
Subject: [PATCH] lisp/progmodes/csharp-mode.el: adjust function-call
 fontification

---
 lisp/progmodes/csharp-mode.el | 40 ++++++++++++++++++-----------------
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index da64daf9848..68eb9dea7f0 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -810,7 +810,25 @@ csharp-ts-mode--font-lock-settings
      (method_declaration type: (_) @font-lock-type-face)
      (method_declaration name: (_) @font-lock-function-name-face)
 
-     (invocation_expression
+     (catch_declaration
+      ((identifier) @font-lock-type-face))
+     (catch_declaration
+      ((identifier) @font-lock-type-face
+       (identifier) @font-lock-variable-name-face))
+
+     (variable_declaration (identifier) @font-lock-type-face)
+     (variable_declarator (identifier) @font-lock-variable-name-face)
+
+     (parameter type: (identifier) @font-lock-type-face)
+     (parameter name: (identifier) @font-lock-variable-name-face)
+
+     (binary_expression (identifier) @font-lock-variable-name-face)
+     (argument (identifier) @font-lock-variable-name-face))
+
+   :language 'c-sharp
+   :feature 'function
+   :override t
+   '((invocation_expression
       (member_access_expression
        (generic_name (identifier) @font-lock-function-name-face)))
      (invocation_expression
@@ -827,23 +845,7 @@ csharp-ts-mode--font-lock-settings
                  (generic_name (type_argument_list
                                 ["<"] @font-lock-bracket-face
                                 (identifier) @font-lock-type-face
-                                [">"] @font-lock-bracket-face)
-                               )])
-
-     (catch_declaration
-      ((identifier) @font-lock-type-face))
-     (catch_declaration
-      ((identifier) @font-lock-type-face
-       (identifier) @font-lock-variable-name-face))
-
-     (variable_declaration (identifier) @font-lock-type-face)
-     (variable_declarator (identifier) @font-lock-variable-name-face)
-
-     (parameter type: (identifier) @font-lock-type-face)
-     (parameter name: (identifier) @font-lock-variable-name-face)
-
-     (binary_expression (identifier) @font-lock-variable-name-face)
-     (argument (identifier) @font-lock-variable-name-face))
+                                [">"] @font-lock-bracket-face))]))
 
    :language 'c-sharp
    :feature 'escape-sequence
@@ -916,7 +918,7 @@ csharp-ts-mode
               '(( comment definition)
                 ( keyword string type)
                 ( constant escape-sequence expression literal property)
-                ( bracket delimiter error)))
+                ( function bracket delimiter error)))
 
   ;; Imenu.
   (setq-local treesit-simple-imenu-settings
-- 
2.37.2

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 811 bytes --]

On 01.01.2023 17:29, Jostein Kjønigsen wrote:
> On 31.12.2022 23:21, Yuan Fu wrote:
>> I applied it, thanks!
>>
>> Yuan
>
> Following up this case, attached is a patch which from what I can tell 
> movies function invocation fontification to level 4, without any other 
> regressions.
>
> Theo: Care to take it for a spin? Does it look OK by you?
>
> -- 
> Jostein

Disregard previous patch.

Consider instead please the patch attached to this email.

It does 3 things all in one:

* moves function-call fontification to level 4 only (in its own feature)

* cleans up long-standing issues with "messy" rules for 
function-invocations. Removes the needs for "overrides".

* also fixes issue with fonctification of self/this-method invocations.

Theo: Can you try this patch and see what you think?

--

Jostein

[-- Attachment #2: 0001-lisp-progmodes-csharp-mode.el-adjust-function-call-f.patch --]
[-- Type: text/x-patch, Size: 3422 bytes --]

From eb3df7b77357a56da9e05163ef0bf0ca9efa97db Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jostein=20Kj=C3=B8nigsen?= <jostein@kjonigsen.net>
Date: Sun, 1 Jan 2023 17:27:06 +0100
Subject: [PATCH] lisp/progmodes/csharp-mode.el: adjust function-call
 fontification

---
 lisp/progmodes/csharp-mode.el | 43 ++++++++++++++++-------------------
 1 file changed, 20 insertions(+), 23 deletions(-)

diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index da64daf9848..02da705b445 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -764,8 +764,12 @@ csharp-ts-mode--font-lock-settings
       (identifier) @font-lock-type-face)
      (type_argument_list
       (identifier) @font-lock-type-face)
-     (generic_name
-      (identifier) @font-lock-type-face)
+     (type_argument_list
+      (generic_name
+       (identifier) @font-lock-type-face))
+     (base_list
+      (generic_name
+       (identifier) @font-lock-type-face))
      (array_type
       (identifier) @font-lock-type-face)
      (cast_expression (identifier) @font-lock-type-face)
@@ -810,26 +814,6 @@ csharp-ts-mode--font-lock-settings
      (method_declaration type: (_) @font-lock-type-face)
      (method_declaration name: (_) @font-lock-function-name-face)
 
-     (invocation_expression
-      (member_access_expression
-       (generic_name (identifier) @font-lock-function-name-face)))
-     (invocation_expression
-      (member_access_expression
-       ((identifier) @font-lock-variable-name-face
-        (identifier) @font-lock-function-name-face)))
-     (invocation_expression
-      (identifier) @font-lock-function-name-face)
-     (invocation_expression
-      (member_access_expression
-       expression: (identifier) @font-lock-variable-name-face))
-     (invocation_expression
-      function: [(generic_name (identifier)) @font-lock-function-name-face
-                 (generic_name (type_argument_list
-                                ["<"] @font-lock-bracket-face
-                                (identifier) @font-lock-type-face
-                                [">"] @font-lock-bracket-face)
-                               )])
-
      (catch_declaration
       ((identifier) @font-lock-type-face))
      (catch_declaration
@@ -845,6 +829,19 @@ csharp-ts-mode--font-lock-settings
      (binary_expression (identifier) @font-lock-variable-name-face)
      (argument (identifier) @font-lock-variable-name-face))
 
+   :language 'c-sharp
+   :feature 'function
+   '((invocation_expression
+      function: (member_access_expression
+                 name: (identifier) @font-lock-function-name-face))
+     (invocation_expression
+      function: (identifier) @font-lock-function-name-face)
+     (invocation_expression
+      function: (member_access_expression
+                 name: (generic_name (identifier) @font-lock-function-name-face)))
+     (invocation_expression
+      function: (generic_name (identifier) @font-lock-function-name-face)))
+
    :language 'c-sharp
    :feature 'escape-sequence
    :override t
@@ -916,7 +913,7 @@ csharp-ts-mode
               '(( comment definition)
                 ( keyword string type)
                 ( constant escape-sequence expression literal property)
-                ( bracket delimiter error)))
+                ( function bracket delimiter error)))
 
   ;; Imenu.
   (setq-local treesit-simple-imenu-settings
-- 
2.37.2

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

[-- Attachment #1.1: Type: text/plain, Size: 1435 bytes --]

On 01.01.2023 18:24, Jostein Kjønigsen wrote:
> Disregard previous patch.
>
> Consider instead please the patch attached to this email.
>
> It does 3 things all in one:
>
> * moves function-call fontification to level 4 only (in its own feature)
>
> * cleans up long-standing issues with "messy" rules for 
> function-invocations. Removes the needs for "overrides".
>
> * also fixes issue with fonctification of self/this-method invocations.
>
> Theo: Can you try this patch and see what you think?
>
> -- 
>
> Jostein

Disregard again (and sorry for the noise!)

I've now gone through several files, done quite a bit of testing myself, 
and found another few issues needing to be solved:

  * Inconsistent variable-name fontification (sometimes when used,
    sometimes when declared, sometimes not when used, sometimes not when
    declared)
  * Variable declaration with explicit generic types
  * new() expression fontification for generic types.
  * Bleeding type-face into brackets for generic return-types in method
    definitions
  * Types when casting through as-expressions are not fontified at all.
  * And more?

I've solved those and combined all this into this latest patch, which 
also moves function-invocation into its own (level 4) feature.

This patch should be well beyond the "85%" which Eli has requested for 
Emacs-29 :)

*Theo:* Could you give this a test-spin, and I promise to call it a day? :)

--
Jostein

[-- Attachment #1.2: Type: text/html, Size: 2209 bytes --]

[-- Attachment #2: 0001-lisp-progmodes-csharp-mode.el-adjust-function-call-f.patch --]
[-- Type: text/x-patch, Size: 6220 bytes --]

From 333602ff341b8a8add15ff96054cfc5cea0116cd Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jostein=20Kj=C3=B8nigsen?= <jostein@kjonigsen.net>
Date: Sun, 1 Jan 2023 17:27:06 +0100
Subject: [PATCH] lisp/progmodes/csharp-mode.el: adjust function-call
 fontification

- ensure method-invocations are highlighted only on level 4
- ensure consistent fontification of variable declarations
  (don't highlight usage of all variables)
- fix issues with highlighting types in new() expressions.
- fix issues with generic types in variable-declarations not using "var".
- use fewer, more general queries for function-invocations. simplify code.
---
 lisp/progmodes/csharp-mode.el | 64 +++++++++++++++++++----------------
 1 file changed, 35 insertions(+), 29 deletions(-)

diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index da64daf9848..473e8f49fd3 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -696,7 +696,7 @@ csharp-ts-mode--font-lock-settings
    :feature 'expression
    '((conditional_expression (identifier) @font-lock-variable-name-face)
      (postfix_unary_expression (identifier)* @font-lock-variable-name-face)
-     (assignment_expression (identifier) @font-lock-variable-name-face))
+     (initializer_expression (assignment_expression left: (identifier) @font-lock-variable-name-face)))
 
    :language 'c-sharp
    :feature 'bracket
@@ -764,8 +764,12 @@ csharp-ts-mode--font-lock-settings
       (identifier) @font-lock-type-face)
      (type_argument_list
       (identifier) @font-lock-type-face)
-     (generic_name
-      (identifier) @font-lock-type-face)
+     (type_argument_list
+      (generic_name
+       (identifier) @font-lock-type-face))
+     (base_list
+      (generic_name
+       (identifier) @font-lock-type-face))
      (array_type
       (identifier) @font-lock-type-face)
      (cast_expression (identifier) @font-lock-type-face)
@@ -773,7 +777,12 @@ csharp-ts-mode--font-lock-settings
      (type_parameter_constraints_clause
       target: (identifier) @font-lock-type-face)
      (type_of_expression (identifier) @font-lock-type-face)
-     (object_creation_expression (identifier) @font-lock-type-face))
+     (object_creation_expression
+      type: (identifier) @font-lock-type-face)
+     (object_creation_expression
+      type: (generic_name (identifier) @font-lock-type-face))
+     (as_expression right: (identifier) @font-lock-type-face)
+     (as_expression right: (generic_name (identifier) @font-lock-type-face)))
 
    :language 'c-sharp
    :feature 'definition
@@ -793,7 +802,6 @@ csharp-ts-mode--font-lock-settings
      (record_declaration (identifier) @font-lock-type-face)
      (namespace_declaration (identifier) @font-lock-type-face)
      (base_list (identifier) @font-lock-type-face)
-     (property_declaration (generic_name))
      (property_declaration
       type: (nullable_type) @font-lock-type-face
       name: (identifier) @font-lock-variable-name-face)
@@ -807,29 +815,10 @@ csharp-ts-mode--font-lock-settings
 
      (constructor_declaration name: (_) @font-lock-type-face)
 
-     (method_declaration type: (_) @font-lock-type-face)
+     (method_declaration type: [(identifier) (void_keyword)] @font-lock-type-face)
+     (method_declaration type: (generic_name (identifier) @font-lock-type-face))
      (method_declaration name: (_) @font-lock-function-name-face)
 
-     (invocation_expression
-      (member_access_expression
-       (generic_name (identifier) @font-lock-function-name-face)))
-     (invocation_expression
-      (member_access_expression
-       ((identifier) @font-lock-variable-name-face
-        (identifier) @font-lock-function-name-face)))
-     (invocation_expression
-      (identifier) @font-lock-function-name-face)
-     (invocation_expression
-      (member_access_expression
-       expression: (identifier) @font-lock-variable-name-face))
-     (invocation_expression
-      function: [(generic_name (identifier)) @font-lock-function-name-face
-                 (generic_name (type_argument_list
-                                ["<"] @font-lock-bracket-face
-                                (identifier) @font-lock-type-face
-                                [">"] @font-lock-bracket-face)
-                               )])
-
      (catch_declaration
       ((identifier) @font-lock-type-face))
      (catch_declaration
@@ -837,13 +826,30 @@ csharp-ts-mode--font-lock-settings
        (identifier) @font-lock-variable-name-face))
 
      (variable_declaration (identifier) @font-lock-type-face)
+     (variable_declaration (generic_name (identifier) @font-lock-type-face))
      (variable_declarator (identifier) @font-lock-variable-name-face)
 
      (parameter type: (identifier) @font-lock-type-face)
+     (parameter type: (generic_name (identifier) @font-lock-type-face))
      (parameter name: (identifier) @font-lock-variable-name-face)
 
-     (binary_expression (identifier) @font-lock-variable-name-face)
-     (argument (identifier) @font-lock-variable-name-face))
+     (lambda_expression (identifier) @font-lock-variable-name-face)
+
+     (declaration_expression type: (identifier) @font-lock-type-face)
+     (declaration_expression name: (identifier) @font-lock-variable-name-face))
+
+   :language 'c-sharp
+   :feature 'function
+   '((invocation_expression
+      function: (member_access_expression
+                 name: (identifier) @font-lock-function-name-face))
+     (invocation_expression
+      function: (identifier) @font-lock-function-name-face)
+     (invocation_expression
+      function: (member_access_expression
+                 name: (generic_name (identifier) @font-lock-function-name-face)))
+     (invocation_expression
+      function: (generic_name (identifier) @font-lock-function-name-face)))
 
    :language 'c-sharp
    :feature 'escape-sequence
@@ -916,7 +922,7 @@ csharp-ts-mode
               '(( comment definition)
                 ( keyword string type)
                 ( constant escape-sequence expression literal property)
-                ( bracket delimiter error)))
+                ( function bracket delimiter error)))
 
   ;; Imenu.
   (setq-local treesit-simple-imenu-settings
-- 
2.37.2

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> On 01.01.2023 18:24, Jostein Kjønigsen wrote:
>> Disregard previous patch.
>>
>> Consider instead please the patch attached to this email.
>>
>> It does 3 things all in one:
>>
>> * moves function-call fontification to level 4 only (in its own feature)
>>
>> * cleans up long-standing issues with "messy" rules for 
>> function-invocations. Removes the needs for "overrides".
>>
>> * also fixes issue with fonctification of self/this-method invocations.
>>
>> Theo: Can you try this patch and see what you think?
>>
>> -- 
>>
>> Jostein
>
> Disregard again (and sorry for the noise!)
>
> I've now gone through several files, done quite a bit of testing myself, 
> and found another few issues needing to be solved:
>
>   * Inconsistent variable-name fontification (sometimes when used,
>     sometimes when declared, sometimes not when used, sometimes not when
>     declared)
>   * Variable declaration with explicit generic types
>   * new() expression fontification for generic types.
>   * Bleeding type-face into brackets for generic return-types in method
>     definitions
>   * Types when casting through as-expressions are not fontified at all.
>   * And more?
>
> I've solved those and combined all this into this latest patch, which 
> also moves function-invocation into its own (level 4) feature.
>
> This patch should be well beyond the "85%" which Eli has requested for 
> Emacs-29 :)
>
> *Theo:* Could you give this a test-spin, and I promise to call it a day? :)
>

Hi!

No worries at all, I'm just glad you found some inspiration :-)

This looks good to me.  I think we are are all set - there are at least
no more features needed.  I guess we can still add some tweaks to the
highlighting itself before the release?

Yuan - you're next ;)

Theo

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Yuan Fu]

Theodor Thornhill <theo@thornhill.no> writes:

> Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
>
>> On 01.01.2023 18:24, Jostein Kjønigsen wrote:
>>> Disregard previous patch.
>>>
>>> Consider instead please the patch attached to this email.
>>>
>>> It does 3 things all in one:
>>>
>>> * moves function-call fontification to level 4 only (in its own feature)
>>>
>>> * cleans up long-standing issues with "messy" rules for 
>>> function-invocations. Removes the needs for "overrides".
>>>
>>> * also fixes issue with fonctification of self/this-method invocations.
>>>
>>> Theo: Can you try this patch and see what you think?
>>>
>>> -- 
>>>
>>> Jostein
>>
>> Disregard again (and sorry for the noise!)
>>
>> I've now gone through several files, done quite a bit of testing myself, 
>> and found another few issues needing to be solved:
>>
>>   * Inconsistent variable-name fontification (sometimes when used,
>>     sometimes when declared, sometimes not when used, sometimes not when
>>     declared)
>>   * Variable declaration with explicit generic types
>>   * new() expression fontification for generic types.
>>   * Bleeding type-face into brackets for generic return-types in method
>>     definitions
>>   * Types when casting through as-expressions are not fontified at all.
>>   * And more?
>>
>> I've solved those and combined all this into this latest patch, which 
>> also moves function-invocation into its own (level 4) feature.
>>
>> This patch should be well beyond the "85%" which Eli has requested for 
>> Emacs-29 :)
>>
>> *Theo:* Could you give this a test-spin, and I promise to call it a day? :)
>>
>
> Hi!
>
> No worries at all, I'm just glad you found some inspiration :-)
>
> This looks good to me.  I think we are are all set - there are at least
> no more features needed.  I guess we can still add some tweaks to the
> highlighting itself before the release?
>
> Yuan - you're next ;)
>
> Theo

Fantastic! I applied the patch, thanks!

Yuan

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

[-- Attachment #1: Type: text/plain, Size: 963 bytes --]


On 02.01.2023 01:12, Yuan Fu wrote:
> Fantastic! I applied the patch, thanks!
>
> Yuan

Great! Thanks!

Please note: The previous patch removed a very wide (generic_name 
(identifier)) selector, which incorrectly caused generic functions to be 
highlighted as a types.

This has lead to having to add in more specific (xxx (generic_name 
(identifier)) selectors around the codebase to compensate, and the 
previous patch evidently didn't have "all" the ones we need.

Attached is a very small patch which should make support for 
highlighting generic types more complete. I won't promise it has 100% 
coverage, but with this in place, I can't see any obvious places in code 
where I'm missing out.

With this in place, the only thing I'd like to improve now (if any) is 
indentation for object-creation/initialization expressions. I've made a 
few attempts and can't get those to behave properly.

Is this anything you could take a look at, Theo? :)

--
Jostein

[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 1168 bytes --]

From 77325442de2b3d2d6d4ffc4223e00c0a956cf256 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jostein=20Kj=C3=B8nigsen?= <jostein@kjonigsen.net>
Date: Sun, 1 Jan 2023 20:46:02 +0100
Subject: [PATCH] Further generic-related improvements.

---
 lisp/progmodes/csharp-mode.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/lisp/progmodes/csharp-mode.el b/lisp/progmodes/csharp-mode.el
index 473e8f49fd3..79afd7f91dc 100644
--- a/lisp/progmodes/csharp-mode.el
+++ b/lisp/progmodes/csharp-mode.el
@@ -773,9 +773,12 @@ csharp-ts-mode--font-lock-settings
      (array_type
       (identifier) @font-lock-type-face)
      (cast_expression (identifier) @font-lock-type-face)
+     (cast_expression (generic_name (identifier) @font-lock-type-face))
      ["operator"] @font-lock-type-face
      (type_parameter_constraints_clause
       target: (identifier) @font-lock-type-face)
+     (type_constraint type: (identifier) @font-lock-type-face)
+     (type_constraint type: (generic_name (identifier) @font-lock-type-face))
      (type_of_expression (identifier) @font-lock-type-face)
      (object_creation_expression
       type: (identifier) @font-lock-type-face)
-- 
2.37.2

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

Yuan: did you forget applying this last patch? :)

—
Jostein Kjønigsen
https://jostein.kjønigsen.net

> On 2 Jan 2023, at 10:59, Jostein Kjønigsen <jostein@secure.kjonigsen.net> wrote:
> 
> 
>> On 02.01.2023 01:12, Yuan Fu wrote:
>> Fantastic! I applied the patch, thanks!
>> 
>> Yuan
> 
> Great! Thanks!
> 
> Please note: The previous patch removed a very wide (generic_name (identifier)) selector, which incorrectly caused generic functions to be highlighted as a types.
> 
> This has lead to having to add in more specific (xxx (generic_name (identifier)) selectors around the codebase to compensate, and the previous patch evidently didn't have "all" the ones we need.
> 
> Attached is a very small patch which should make support for highlighting generic types more complete. I won't promise it has 100% coverage, but with this in place, I can't see any obvious places in code where I'm missing out.
> 
> With this in place, the only thing I'd like to improve now (if any) is indentation for object-creation/initialization expressions. I've made a few attempts and can't get those to behave properly.
> 
> Is this anything you could take a look at, Theo? :)
> 
> --
> Jostein
> <patch.txt>

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Jostein Kjønigsen]

On 03.01.2023 06:43, Jostein Kjønigsen wrote:
> Yuan: did you forget applying this last patch? :)
>
> —
> Jostein Kjønigsen
> https://jostein.kjønigsen.net
>
>> On 2 Jan 2023, at 10:59, Jostein Kjønigsen <jostein@secure.kjonigsen.net> wrote:
>> Great! Thanks!
>>
>> Please note: The previous patch removed a very wide (generic_name (identifier)) selector, which incorrectly caused generic functions to be highlighted as a types.
>>
>> This has lead to having to add in more specific (xxx (generic_name (identifier)) selectors around the codebase to compensate, and the previous patch evidently didn't have "all" the ones we need.
>>
>> Attached is a very small patch which should make support for highlighting generic types more complete. I won't promise it has 100% coverage, but with this in place, I can't see any obvious places in code where I'm missing out.
>>
>> With this in place, the only thing I'd like to improve now (if any) is indentation for object-creation/initialization expressions. I've made a few attempts and can't get those to behave properly.
>>
>> Is this anything you could take a look at, Theo? :)
>>
>> --
>> Jostein
>> <patch.txt>

Given the feature-freeze on emacs-29 now, could someone please get the 
above patch installed?

That would at least make me feel more comfortable :)

--
Jostein

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Yuan Fu]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> Yuan: did you forget applying this last patch? :)

Don’t worry, I didn’t ;-) Since you asked Theo for confirmation I
thought I’d wait for his reply.

Yuan

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 3 January 2023 07:51:55 CET, Yuan Fu <casouri@gmail.com> wrote:
>
>Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:
>
>> Yuan: did you forget applying this last patch? :)
>
>Don’t worry, I didn’t ;-) Since you asked Theo for confirmation I
>thought I’d wait for his reply.
>
>Yuan

I think he meant the indentation fix in a separate patch.

I'll look at it today, Jostein :)

Theo 

bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features

[Yuan Fu]

Jostein Kjønigsen <jostein@secure.kjonigsen.net> writes:

> On 03.01.2023 06:43, Jostein Kjønigsen wrote:
>> Yuan: did you forget applying this last patch? :)
>>
>> —
>> Jostein Kjønigsen
>> https://jostein.kjønigsen.net
>>
>>> On 2 Jan 2023, at 10:59, Jostein Kjønigsen <jostein@secure.kjonigsen.net> wrote:
>>> Great! Thanks!
>>>
>>> Please note: The previous patch removed a very wide (generic_name
>>> (identifier)) selector, which incorrectly caused generic functions
>>> to be highlighted as a types.
>>>
>>> This has lead to having to add in more specific (xxx (generic_name
>>> (identifier)) selectors around the codebase to compensate, and the
>>> previous patch evidently didn't have "all" the ones we need.
>>>
>>> Attached is a very small patch which should make support for
>>> highlighting generic types more complete. I won't promise it has
>>> 100% coverage, but with this in place, I can't see any obvious
>>> places in code where I'm missing out.
>>>
>>> With this in place, the only thing I'd like to improve now (if any)
>>> is indentation for object-creation/initialization expressions. I've
>>> made a few attempts and can't get those to behave properly.
>>>
>>> Is this anything you could take a look at, Theo? :)
>>>
>>> --
>>> Jostein
>>> <patch.txt>
>
> Given the feature-freeze on emacs-29 now, could someone please get the
> above patch installed?
>
> That would at least make me feel more comfortable :)

Theo hasn’t get back yet but I’m sure the patch is good, so I just
applied it :-)

Yuan