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

Previous Next

Full log

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.

Previous Next

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