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

[Eli Zaretskii <eliz@gnu.org>]

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