From: Eli Zaretskii <eliz@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel@gnu.org, pedz@easesoftware.com
Subject: Re: Cutoff date for adding ruby-ts-mode?
Date: Fri, 30 Dec 2022 10:16:33 +0200 [thread overview]
Message-ID: <83mt7571cu.fsf@gnu.org> (raw)
In-Reply-To: <00b1ed5e-271b-fab7-cace-b6a04ac6fd46@yandex.ru> (message from Dmitry Gutov on Thu, 29 Dec 2022 23:39:37 +0200)
> Date: Thu, 29 Dec 2022 23:39:37 +0200
> Cc: Perry Smith <pedz@easesoftware.com>
> From: Dmitry Gutov <dgutov@yandex.ru>
>
> Hi all and Eli in particular,
>
> How close are we to "hard freeze" date of Emacs 29, after which no new
> tree-sitter modes should be added?
You have a day or two, and I hope this should be enough for adding new
features. (If they have still some rough edges, that could be fixed
later on.)
> I'm told the copyright papers might be signed next week.
>
> The code is largely functional: font-lock just needs minor updates; the
> indentation has more problems, but it's still probably better to have
> the new mode in Emacs 29, rather than not.
So I suggest you install that ASAP.
> Also regarding indentation, Ruby community uses a bunch of different
> styles, and it was my impression (could be wrong, though) that Perry
> wanted to at least have ruby-ts-mode be able to use a different style
> than what is currently ruby-mode's default. To that end, he implemented
> a couple of user options.
>
> In bug#60186, I also implement a bunch of options that allow similar
> flexibility to the users of "plain" ruby-mode. I believe rather than
> have different incompatible options, it would be better to unify them
> between the modes, at least where the capabilities match, to use the
> same options.
I agree that having compatible options makes sense, provided that
changes in ruby-mode that affect existing/default indentation style
and font-lock are relatively safe.
> So... if there is still time to get ruby-ts-mode in (and give it a
> little polish), it might be a good idea to get the patch for bug#60186
> in first. Alternatively, it could come with non-customizable indentation
> (options would be added later), or it could have a set of customization
> points which we'll promptly deprecate right after (ones that will become
> redundant).
>
> Or we defer all that and release both new options in ruby-mode and
> ruby-ts-mode from master to GNU ELPA.
It's up to you. If the above-mentioned method suits you, we can have
that on the release branch.
next prev parent reply other threads:[~2022-12-30 8:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-29 21:39 Cutoff date for adding ruby-ts-mode? Dmitry Gutov
2022-12-30 8:16 ` Eli Zaretskii [this message]
2022-12-30 15:32 ` Dmitry Gutov
2022-12-30 16:59 ` Eli Zaretskii
2022-12-30 21:42 ` Dmitry Gutov
2022-12-31 6:31 ` Eli Zaretskii
2022-12-31 11:24 ` Stefan Kangas
2023-01-02 1:35 ` Dmitry Gutov
2023-01-02 12:51 ` Eli Zaretskii
2023-01-02 18:44 ` Juri Linkov
2023-01-03 1:22 ` Dmitry Gutov
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83mt7571cu.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=pedz@easesoftware.com \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).