From: "Jostein Kjønigsen" <jostein@secure.kjonigsen.net>
To: Eli Zaretskii <eliz@gnu.org>, jostein@kjonigsen.net
Cc: 60376@debbugs.gnu.org, casouri@gmail.com, theo@thornhill.no
Subject: bug#60376: 29.0.60; Standardize csharp-ts-mode's font-lock features
Date: Fri, 30 Dec 2022 15:39:20 +0100 [thread overview]
Message-ID: <785dab0b-1b9b-6479-9e17-25effdff2ba2@secure.kjonigsen.net> (raw)
In-Reply-To: <838rip6kq3.fsf@gnu.org>
On 30.12.2022 15:15, Eli Zaretskii wrote:
>> Ok. That's unfortunate timing.
>> To be clear, I think it's absolutely realistic to get csharp-ts-mode to
>> adhere to some of the guidelines outlined in the
>> tree-sitter-standardization thread.
>>
>> But it's completely unrealistic (at least on my part) to get any
>> well-crafted and well-tested changes into csharp-ts-mode until after
>> new-years.
> If you can come up with a 85% correct code soon, and leave the rest
> for bug-fixing, that's also acceptable.
>
> Otherwise, please understand my POV: we do want to release Emacs 29
> soon. The tree-sitter related features already got a full month of
> slack, whereby new features were acceptable on the release branch. If
> we keep delaying the freeze, we will not release Emacs 29 any time
> soon. You have all been here for the past month, and I announced the
> rules loud and clear, so if some modes are still not up to speed with
> the latest treesit.el changes, then it's too bad, but we will have to
> wait for Emacs 30 with those. I'm sorry, but we do need to draw the
> line in the sand at some point: people are waiting for Emacs 29, and
> we cannot disappoint them.
I completely understand.
I've left some thoughts about the standardization-process -in general-
in the Emacs-devel thread, on how we should "cope" with exactly that
situation.
To be clear: I think csharp-ts-mode works well beyond 85% (it's what I
use as my daily driver), but the syntax-highlighting at level 3 may be
more excessive than some people (like Stefan) prefer.
If we instead for these "major" changes suggested by Yuan, instead aim
for just moving some "smaller" implementation-detail
(function-invocations and property-highlighting) to level 4, I think we
she be able to get something which is mostly what Stefan would expect
and prefer, and it would be a much smaller change.
Then we can take a look at those bigger changes (standardized features,
enabling/disabling them individually, as end-users, etc) for Emacs-30.
I think that's a more realistic plan. Does that sound OK?
--
Jostein
next prev parent reply other threads:[~2022-12-30 14:39 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
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 [this message]
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=785dab0b-1b9b-6479-9e17-25effdff2ba2@secure.kjonigsen.net \
--to=jostein@secure.kjonigsen.net \
--cc=60376@debbugs.gnu.org \
--cc=casouri@gmail.com \
--cc=eliz@gnu.org \
--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.