From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= Newsgroups: gmane.emacs.bugs Subject: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features Date: Thu, 29 Dec 2022 22:03:06 +0100 Message-ID: References: Reply-To: jostein@kjonigsen.net Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------m3S8A8W0wNE023hgssGziAF7" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32087"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1 Cc: Theodor Thornhill To: Yuan Fu , 60376@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 29 22:06:48 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pB06w-00089E-Kw for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 29 Dec 2022 22:06:48 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pB04M-0001JP-O9; Thu, 29 Dec 2022 16:04:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pB04K-0001Io-IL for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2022 16:04:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pB04I-0000PZ-DD for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2022 16:04:04 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pB04H-0008Tt-Pc for bug-gnu-emacs@gnu.org; Thu, 29 Dec 2022 16:04:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Jostein =?UTF-8?Q?Kj=C3=B8nigsen?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 29 Dec 2022 21:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60376 X-GNU-PR-Package: emacs Original-Received: via spool by 60376-submit@debbugs.gnu.org id=B60376.167234780232550 (code B ref 60376); Thu, 29 Dec 2022 21:04:01 +0000 Original-Received: (at 60376) by debbugs.gnu.org; 29 Dec 2022 21:03:22 +0000 Original-Received: from localhost ([127.0.0.1]:33033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pB03d-0008Sv-1s for submit@debbugs.gnu.org; Thu, 29 Dec 2022 16:03:21 -0500 Original-Received: from wout4-smtp.messagingengine.com ([64.147.123.20]:57103) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pB03a-0008Sf-36 for 60376@debbugs.gnu.org; Thu, 29 Dec 2022 16:03:19 -0500 Original-Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id EF97332005BC; Thu, 29 Dec 2022 16:03:11 -0500 (EST) Original-Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 29 Dec 2022 16:03:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= secure.kjonigsen.net; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:reply-to:sender:subject:subject:to:to; s=fm1; t= 1672347791; x=1672434191; bh=tmplBodXn2e0NhNb4N18W+pE66Yzz4eBrN8 IJphsWf4=; b=cP9Hs2kZlgej4nITlrzZ78D+Jh9MME39IJgvkX4Q/1Og3WOzFOy 8iAiSsB1T3OJLibMTJAUD2FzIVSHShMXNsfHvC9hBiwndf/pDn3pqMNxMpRpeVK1 gNrjw5vLU1q3FTz8j9S8U0YCNudxbbONPmuprCImcjpAvSK53QkmkGFNhBE2xpPx GogXLJ0lwu1uL9Q+0ZlyJCR8sdkilQW3agdShOfN+ZbGmFwGw/rpTHOCoYTRht1t tyQvSvPxnW6EVoUjB0WQfSxigfCWcfVVTtQ4q8Wg5CkkE/t6N+hWrae6hA0bkEGX lwO1RPDWf3hAU0nvJ3qXnP2iBA1OJ+q23Zg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1672347791; x=1672434191; bh=tmplBodXn2e0N hNb4N18W+pE66Yzz4eBrN8IJphsWf4=; b=NU64WpVfvpQNXVdjZNKHUxm/NI96S DlP60AYOkaLEjan98UOaV/DiiymDWzVbHAIdjMvDIl6Jy8/0PFGSmJVLBSB5yMZ/ TvyNk8+j4H7JHLefp/thN2IDPL3XoaTQw0vFakG+x88IiT/1Z51OnXbrYPj7+ctr pup3dCWruM0nIGtHWoZJ/L1CXSUAbY1CXEu/nLub+0PycsnPuMfKrM/V0OdsCJoV 6mR181dMwDn/pRi55sMiSqtHgH3x2vaVyXgkvL0YwCCndo3PYLfndd8pX3bH9raj pXTdbdEm4ivsPzNXbTtHj/C6e3aVsDD1c3qU+1UwBuysYrrh6IMKagvWw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrieeggddugeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfkffggfghruffvvehfhfgjsegrtderredtfeejnecuhfhrohhmpeflohhs thgvihhnucfmjhppnhhighhsvghnuceojhhoshhtvghinhesshgvtghurhgvrdhkjhhonh highhsvghnrdhnvghtqeenucggtffrrghtthgvrhhnpeeiudejgedthfejieehteefvdfh ffejhfdvfeduteehtdevjeelhffgudehgfdvueenucffohhmrghinhepghhnuhdrohhrgh dpkhhjnhhighhsvghnrdhnohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehjohhsthgvihhnsehsvggtuhhrvgdrkhhjohhnihhgshgvnhdrnh gvth X-ME-Proxy: Feedback-ID: ib2f84088:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 29 Dec 2022 16:03:10 -0500 (EST) Content-Language: en-GB, nb-NO In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252060 Archived-At: This is a multi-part message in MIME format. --------------m3S8A8W0wNE023hgssGziAF7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 } --------------m3S8A8W0wNE023hgssGziAF7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

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
}
--------------m3S8A8W0wNE023hgssGziAF7--