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

[Dmitry Gutov <dgutov@yandex.ru>]

On 30/12/2022 18:59, Eli Zaretskii wrote:
>> Date: Fri, 30 Dec 2022 17:32:47 +0200
>> Cc: emacs-devel@gnu.org, pedz@easesoftware.com,
>>   Stefan Monnier <monnier@IRO.UMontreal.CA>
>> From: Dmitry Gutov <dgutov@yandex.ru>
>>
>> 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.
> 
> I'd like to avoid any more decisions related to *-ts-mode's, let alone
> binding ones.  I'd like to leave that for the future, when we
> (hopefully) will have a clearer picture of how best to mix
> tree-sitter-supported modes with the traditional ones.
> 
> So renaming now doesn't sound like a good idea to me.

I like to defer decisions too, but this comes with consequences. E.g. if 
we release ELPA packages with certain names, and later change the names, 
people who already installed the previous names will stop getting 
updates, but won't know to switch to the new names. Unless they read 
about it on Reddit or etc.

So it's something to do as rarely as possible.

>> 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.
> 
> I'd prefer this alternative for now (modulo the separate ELPA packages
> part, which I leave for you to decide: they could also be a single
> package from my POV).  If nothing else, having separate files is
> similar to what at least some other *-ts-mode's do.  When we revisit
> these issues in the future, we'll be able to make the decisions about
> all of them.

Okay.

I wonder what's going to happen if we release Emacs 29 with ruby-mode 
and ruby-ts-mode in separate files, and then later add a package called 
'ruby' to ELPA with ruby.el containing both modes.

Will the autoloads file from an ELPA package always take priority over 
the built-in autoloads? If yes, then we don't have to do anything now. 
Hopefully that's not undefined behavior.

Alternatively, it would be possible to release two files as one ELPA 
package, but it would seem to require a third file: one matching the 
package name, ruby.el.