From: "Jostein Kjønigsen" <jostein@secure.kjonigsen.net>
To: Yuan Fu <casouri@gmail.com>, 60376@debbugs.gnu.org
Cc: Theodor Thornhill <theo@thornhill.no>
Subject: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features
Date: Thu, 29 Dec 2022 22:03:06 +0100 [thread overview]
Message-ID: <d3192062-f5b4-b80f-70b3-7d99057f280b@secure.kjonigsen.net> (raw)
In-Reply-To: <C2E6DF88-CD19-4B13-BD48-E85039EC58A0@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4342 bytes --]
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 <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
}
[-- Attachment #2: Type: text/html, Size: 6823 bytes --]
next prev parent reply other threads:[~2022-12-29 21:03 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-28 8:25 bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features Yuan Fu
2022-12-29 19:55 ` Yuan Fu
2022-12-29 21:03 ` Jostein Kjønigsen [this message]
2022-12-30 8:21 ` Eli Zaretskii
2022-12-29 22:16 ` Yuan Fu
2022-12-30 8:19 ` Eli Zaretskii
2022-12-30 13:35 ` Jostein Kjønigsen
2022-12-30 14:15 ` Eli Zaretskii
2022-12-30 14:39 ` Jostein Kjønigsen
2022-12-30 15:39 ` Eli Zaretskii
2022-12-30 17:35 ` Jostein Kjønigsen
2022-12-30 19:30 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-31 9:53 ` Jostein Kjønigsen
2022-12-31 10:32 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-30 14:40 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-12-30 15:04 ` Jostein Kjønigsen
2022-12-31 22:21 ` Yuan Fu
2023-01-01 16:29 ` Jostein Kjønigsen
2023-01-01 17:24 ` Jostein Kjønigsen
2023-01-01 18:14 ` Jostein Kjønigsen
2023-01-01 18:41 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-02 0:12 ` Yuan Fu
2023-01-02 9:59 ` Jostein Kjønigsen
2023-01-03 5:43 ` Jostein Kjønigsen
2023-01-05 21:27 ` Jostein Kjønigsen
2023-01-03 6:51 ` Yuan Fu
2023-01-03 7:20 ` Theodor Thornhill via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-06 5:55 ` Yuan Fu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d3192062-f5b4-b80f-70b3-7d99057f280b@secure.kjonigsen.net \
--to=jostein@secure.kjonigsen.net \
--cc=60376@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=jostein@kjonigsen.net \
--cc=theo@thornhill.no \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.