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