[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Cutoff date for adding ruby-ts-mode?
From: |
Eli Zaretskii |
Subject: |
Re: Cutoff date for adding ruby-ts-mode? |
Date: |
Fri, 30 Dec 2022 10:16:33 +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.