emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dmitry Gutov
Subject: Re: Cutoff date for adding ruby-ts-mode?
Date: Fri, 30 Dec 2022 17:32:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]