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

Previous Next

Full log

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)]

Previous Next

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