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

Previous Next

Full log

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

Previous Next

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