Re: Cutoff date for adding ruby-ts-mode?

[Eli Zaretskii]

> 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.