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

[Jostein Kjønigsen]

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@kjonigsen.net 🍵 jostein@gmail.com
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
}