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

[Dmitry Gutov <dgutov@yandex.ru>]

On 30/12/2022 10:16, Eli Zaretskii wrote:
>> 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.)

Thanks, I'll try to verify now that everything is good with the pieces 
involved and get on with that.

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

All right.

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

The latest revision of the patch seems particularly safe to me (like 
with previous option, no substantially different code is running as long 
as all the options are at their default values). But I'm waiting to hear 
back from Aaron regarding his experience. It has extra regression tests, 
though.

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

All right. This was more of a "yes" than I expected. With apologies, let 
me try to push a little further.

Speaking of the method, how do you feel about renaming a file?

If ruby-ts-mode is going to live in the same file as ruby-mode, perhaps 
the more neutral file name ruby.el would be proper? This would be in 
line with the scheme used by js.el and python.el.

This is not an idle lets-decide-it-later question because I want to have 
some later releases of these modes in GNU ELPA, and we'll want to have 
the built-in packages properly shadowed when someone installs a new 
version. (Perhaps Stefan has an advice here, so Cc'd).

I see several (require 'ruby-mode)-s in third-party packages. There are 
not too many of them, I could just go around and ask everyone to replace 
that with (or (require 'ruby nil t) (require 'ruby-mode)). Or we could 
have a compatibility stub in Emacs 29 where ruby-mode.el just calls 
"(require 'ruby) (provide 'ruby-mode)".

We don't often rename files also because of 'git log' problems, but we 
have a decent (and simple enough) plan to improve that in bug#55871.

Alternatively, we break from the common scheme and put the modes in 
separate files, one depending on the other. Then they'll have to be 
separate GNU ELPA packages (I think), and we'll need to synchronously 
bump version and required-version in them every time when making 
interrelated changes in the future.