GNU bug report logs - #60376
29.0.60; Standardize csharp-ts-mode's font-lock features

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 60376 in the body.
You can then email your comments to 60376 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: Yuan Fu <casouri <at> gmail.com>
To: Bug Report Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 29.0.60; Standardize csharp-ts-mode's font-lock features
Date: Wed, 28 Dec 2022 00:25:24 -0800

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
}

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

From: Yuan Fu <casouri <at> gmail.com>
To: 60376 <at> debbugs.gnu.org
Cc: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock 
 features
Date: Thu, 29 Dec 2022 11:55:15 -0800

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

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Yuan Fu <casouri <at> gmail.com>, 60376 <at> debbugs.gnu.org
Cc: Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Thu, 29 Dec 2022 22:03:06 +0100

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

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 <at> kjonigsen.net 🍵 jostein <at> 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
}

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

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

From: Yuan Fu <casouri <at> gmail.com>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock 
 features
Date: Thu, 29 Dec 2022 14:16:13 -0800

Jostein Kjønigsen <jostein <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Yuan Fu <casouri <at> gmail.com>
Cc: 60376 <at> debbugs.gnu.org, jostein <at> secure.kjonigsen.net, jostein <at> kjonigsen.net,
 theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60;
 Standardize csharp-ts-mode's font-lock  features
Date: Fri, 30 Dec 2022 10:19:41 +0200

> Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
> From: Yuan Fu <casouri <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: jostein <at> kjonigsen.net
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60;
 Standardize csharp-ts-mode's font-lock features
Date: Fri, 30 Dec 2022 10:21:24 +0200

> Cc: Theodor Thornhill <theo <at> thornhill.no>
> Date: Thu, 29 Dec 2022 22:03:06 +0100
> From: Jostein Kjønigsen <jostein <at> 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.

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>, Yuan Fu <casouri <at> gmail.com>
Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Fri, 30 Dec 2022 14:35:46 +0100

Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
>> From: Yuan Fu <casouri <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: jostein <at> kjonigsen.net
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com, jostein <at> kjonigsen.net,
 theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Fri, 30 Dec 2022 16:15:48 +0200

> Date: Fri, 30 Dec 2022 14:35:46 +0100
> Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
> From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
> 
> Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
> >> From: Yuan Fu <casouri <at> 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.

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>, jostein <at> kjonigsen.net
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Fri, 30 Dec 2022 15:39:20 +0100

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

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Eli Zaretskii <eliz <at> gnu.org>, jostein <at> kjonigsen.net
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features
Date: Fri, 30 Dec 2022 15:40:49 +0100

On 30 December 2022 15:15:48 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Fri, 30 Dec 2022 14:35:46 +0100
>> Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
>> From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
>> 
>> Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
>> >> From: Yuan Fu <casouri <at> 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

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, casouri <at> gmail.com
Subject: Re: bug#60376: 29.0.60;
 Standardize csharp-ts-mode's font-lock features
Date: Fri, 30 Dec 2022 16:04:34 +0100

> On 30 Dec 2022, at 15:42, Theodor Thornhill <theo <at> thornhill.no> wrote:
> 
> 
> 
> On 30 December 2022 15:15:48 CET, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> Date: Fri, 30 Dec 2022 14:35:46 +0100
>>> Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
>>> From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
>>> 
>>> Cc: 60376 <at> debbugs.gnu.org, jostein <at> kjonigsen.net, theo <at> thornhill.no
>>>>> From: Yuan Fu <casouri <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: jostein <at> kjonigsen.net
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Fri, 30 Dec 2022 17:39:04 +0200

> Date: Fri, 30 Dec 2022 15:39:20 +0100
> Cc: casouri <at> gmail.com, 60376 <at> debbugs.gnu.org, theo <at> thornhill.no
> From: Jostein Kjønigsen <jostein <at> 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.

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com, theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60;
 Standardize csharp-ts-mode's font-lock features
Date: Fri, 30 Dec 2022 18:35:48 +0100

> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> 
>> 
>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>> Cc: casouri <at> gmail.com, 60376 <at> debbugs.gnu.org, theo <at> thornhill.no
>> From: Jostein Kjønigsen <jostein <at> 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

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>, Eli
 Zaretskii <eliz <at> gnu.org>
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Fri, 30 Dec 2022 20:30:43 +0100

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

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

>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>> 
>>> 
>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>> Cc: casouri <at> gmail.com, 60376 <at> debbugs.gnu.org, theo <at> thornhill.no
>>> From: Jostein Kjønigsen <jostein <at> 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

[0001-Tweak-csharp-mode-font-lock-settings.patch (text/x-diff, attachment)]

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Theodor Thornhill <theo <at> thornhill.no>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Sat, 31 Dec 2022 10:53:54 +0100

On 30.12.2022 20:30, Theodor Thornhill wrote:
> Jostein Kjønigsen <jostein <at> secure.kjonigsen.net> writes:
>
>>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>
>>> 
>>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>>> Cc: casouri <at> gmail.com, 60376 <at> debbugs.gnu.org, theo <at> thornhill.no
>>>> From: Jostein Kjønigsen <jostein <at> 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

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: jostein <at> kjonigsen.net,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 Eli Zaretskii <eliz <at> gnu.org>
Cc: 60376 <at> debbugs.gnu.org, casouri <at> gmail.com
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features
Date: Sat, 31 Dec 2022 11:32:54 +0100

On 31 December 2022 10:53:54 CET, "Jostein Kjønigsen" <jostein <at> secure.kjonigsen.net> wrote:
>On 30.12.2022 20:30, Theodor Thornhill wrote:
>> Jostein Kjønigsen <jostein <at> secure.kjonigsen.net> writes:
>> 
>>>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>> 
>>>> 
>>>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>>>> Cc: casouri <at> gmail.com, 60376 <at> debbugs.gnu.org, theo <at> thornhill.no
>>>>> From: Jostein Kjønigsen <jostein <at> 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

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

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>,
 Eli Zaretskii <eliz <at> gnu.org>, jostein <at> kjonigsen.net, 60376 <at> debbugs.gnu.org
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock 
 features
Date: Sat, 31 Dec 2022 14:21:24 -0800

Theodor Thornhill <theo <at> thornhill.no> writes:

> On 31 December 2022 10:53:54 CET, "Jostein Kjønigsen" <jostein <at> secure.kjonigsen.net> wrote:
>>On 30.12.2022 20:30, Theodor Thornhill wrote:
>>> Jostein Kjønigsen <jostein <at> secure.kjonigsen.net> writes:
>>> 
>>>>> On 30 Dec 2022, at 16:46, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>>>> 
>>>>> 
>>>>>> Date: Fri, 30 Dec 2022 15:39:20 +0100
>>>>>> Cc: casouri <at> gmail.com, 60376 <at> debbugs.gnu.org, theo <at> thornhill.no
>>>>>> From: Jostein Kjønigsen <jostein <at> 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

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Yuan Fu <casouri <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Sun, 1 Jan 2023 17:29:19 +0100

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

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

[0001-lisp-progmodes-csharp-mode.el-adjust-function-call-f.patch (text/x-patch, attachment)]

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Yuan Fu <casouri <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Sun, 1 Jan 2023 18:24:32 +0100

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

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

[0001-lisp-progmodes-csharp-mode.el-adjust-function-call-f.patch (text/x-patch, attachment)]

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Yuan Fu <casouri <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Sun, 1 Jan 2023 19:14:02 +0100

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

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

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

[0001-lisp-progmodes-csharp-mode.el-adjust-function-call-f.patch (text/x-patch, attachment)]

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: jostein <at> kjonigsen.net, Yuan Fu <casouri <at> gmail.com>
Cc: 60376 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Sun, 01 Jan 2023 19:41:33 +0100

Jostein Kjønigsen <jostein <at> 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

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

From: Yuan Fu <casouri <at> gmail.com>
To: Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, eliz <at> gnu.org, jostein <at> kjonigsen.net
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock 
 features
Date: Sun, 1 Jan 2023 16:12:24 -0800

Theodor Thornhill <theo <at> thornhill.no> writes:

> Jostein Kjønigsen <jostein <at> 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

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Yuan Fu <casouri <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Mon, 2 Jan 2023 10:59:39 +0100

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

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 (text/plain, attachment)]

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Yuan Fu <casouri <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#60376: 29.0.60;
 Standardize csharp-ts-mode's font-lock features
Date: Tue, 3 Jan 2023 06:43:23 +0100

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

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

From: Yuan Fu <casouri <at> gmail.com>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: 60376 <at> debbugs.gnu.org, eliz <at> gnu.org, theo <at> thornhill.no
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock 
 features
Date: Mon, 2 Jan 2023 22:51:55 -0800

Jostein Kjønigsen <jostein <at> 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

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

From: Theodor Thornhill <theo <at> thornhill.no>
To: Yuan Fu <casouri <at> gmail.com>,
 Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: 60376 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock  features
Date: Tue, 03 Jan 2023 08:20:43 +0100

On 3 January 2023 07:51:55 CET, Yuan Fu <casouri <at> gmail.com> wrote:
>
>Jostein Kjønigsen <jostein <at> 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 

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

From: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
To: Yuan Fu <casouri <at> gmail.com>, Theodor Thornhill <theo <at> thornhill.no>
Cc: 60376 <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock
 features
Date: Thu, 5 Jan 2023 22:27:28 +0100

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

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

From: Yuan Fu <casouri <at> gmail.com>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: 60376 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 60376-done <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock 
 features
Date: Thu, 5 Jan 2023 22:55:39 -0700

Jostein Kjønigsen <jostein <at> 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 <at> 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

Previous Next

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