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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Yuan Fu <casouri <at> gmail.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#60376: closed (29.0.60; Standardize csharp-ts-mode's
 font-lock features)
Date: Fri, 06 Jan 2023 05:56:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Thu, 5 Jan 2023 22:55:39 -0700
with message-id <D03CE8EB-D7BC-44EF-B8D8-90F81CF8FF59 <at> gmail.com>
and subject line Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock  features
has caused the debbugs.gnu.org bug report #60376,
regarding 29.0.60; Standardize csharp-ts-mode's font-lock features
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
60376: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60376
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Yuan Fu <casouri <at> gmail.com>
To: Bug Report Emacs <bug-gnu-emacs <at> gnu.org>
Subject: 29.0.60; Standardize csharp-ts-mode's font-lock features
Date: Wed, 28 Dec 2022 00:25:24 -0800

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 3 (message/rfc822, inline)]

From: Yuan Fu <casouri <at> gmail.com>
To: Jostein Kjønigsen <jostein <at> secure.kjonigsen.net>
Cc: 60376 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 60376-done <at> debbugs.gnu.org, Theodor Thornhill <theo <at> thornhill.no>
Subject: Re: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock 
 features
Date: Thu, 5 Jan 2023 22:55:39 -0700

Jostein Kjønigsen <jostein <at> secure.kjonigsen.net> writes:

> On 03.01.2023 06:43, Jostein Kjønigsen wrote:
>> Yuan: did you forget applying this last patch? :)
>>
>> —
>> Jostein Kjønigsen
>> https://jostein.kjønigsen.net
>>
>>> On 2 Jan 2023, at 10:59, Jostein Kjønigsen <jostein <at> secure.kjonigsen.net> wrote:
>>> Great! Thanks!
>>>
>>> Please note: The previous patch removed a very wide (generic_name
>>> (identifier)) selector, which incorrectly caused generic functions
>>> to be highlighted as a types.
>>>
>>> This has lead to having to add in more specific (xxx (generic_name
>>> (identifier)) selectors around the codebase to compensate, and the
>>> previous patch evidently didn't have "all" the ones we need.
>>>
>>> Attached is a very small patch which should make support for
>>> highlighting generic types more complete. I won't promise it has
>>> 100% coverage, but with this in place, I can't see any obvious
>>> places in code where I'm missing out.
>>>
>>> With this in place, the only thing I'd like to improve now (if any)
>>> is indentation for object-creation/initialization expressions. I've
>>> made a few attempts and can't get those to behave properly.
>>>
>>> Is this anything you could take a look at, Theo? :)
>>>
>>> --
>>> Jostein
>>> <patch.txt>
>
> Given the feature-freeze on emacs-29 now, could someone please get the
> above patch installed?
>
> That would at least make me feel more comfortable :)

Theo hasn’t get back yet but I’m sure the patch is good, so I just
applied it :-)

Yuan

Previous Next

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