Placeholder for potential Raku name-change implications

[treyharris]

This issue is to discuss and track what may need doing for Raku/user-experience#19 and Raku/problem-solving#89 if the language name changes (most likely to Raku).

Please note: I am not taking a position on the renaming by opening this issue, and I’d kindly request this issue not be used for any discussion of the renaming proposal itself. It’s simply the reality that, if and when the name changes, this mode will have to change too.

A non-exhaustive list of tasks:

• Accepting and recognizing new files:
  • extension-free executable Raku scripts in addition to Perl 6 ones, and
  • filename extensions mentioned in Path to raku problem-solving#89—currently, .raku, .rakumod, and .rakutest, though .t will continue to be available and all legacy extensions like .pm6 will continue to be supported.
• Changing the name of the library, and its functions, exposed variables, faces, keymaps, and hooks—and, where possible, creating aliases to the old ones.
• Getting the library under the new name into MELPA.

A few questions for clarification:

MELPA

1. Do we try to change the name of the package, or simply begin exporting raku-mode and let the last version of perl6-mode continue to live for some period?
2. Do we include a perl6-mode (either in the form of a version of perl6-mode.el, or a handler in a raku-mode library) in the distribution, or do we depend on the perl6-mode package?
3. If we do depend on the other package, same question for nqp: do we provide it in raku-mode, or depend on the other package’s?
4. Assuming we do not have raku-mode become a dependent of perl6-mode, what should we do when we’re loaded in an Emacs that also has a perl6-mode loaded?
5. Do we formally obsolete perl6-.* names at some point? If yes, when and on what schedule?

Package migration

How can we transition users of the existing package? We can’t do much that will work for all those who use init files replete with hardcoding, but we could be able to make use of some Emacs features for migration.

If we had made more use of certain customization features this would be easier, but for now, out of about two dozen available customizations, just one—the variable perl6-indent-offset—uses Easy Customization. Easy Customization settings are the only customizations we can safely migrate in-place.

Making raku-mode a derived mode of perl6-mode would help with some of this—for instance, key bindings will be preserved, no matter how the user set them for perl6-mode, as will snippets, some hooks, and many other bits and bobs.

But the transition path for a mode derived from perl6-mode evolving into one derived from prog-mode (e.g., changing raku-mode to eventually become a sibling to, rather than child of, perl6-mode) is not well-defined—searching around, I’m not sure this has been done before with a language already having a published Emacs package.

Development roadmap

I think we can all agree on two points:

1. We want perl6-mode to go away as a prerequisite, at least eventually, and
2. In the meantime, post-name-change, we don’t want all enhancements and bugfixes to have to be made in perl6-mode—we’d want to manage just a single development source.

Let me reiterate that these points apply if and when the name change happens. I wouldn’t expect agreement on these points otherwise!

I think this leaves us with a big early decision:

1. Do a hard cutover from perl6-mode by creating a new repo with source code cloned from this one,¹ and just globally string-replace raku for perl6, adding the new file extensions and shebang recognizer (adding, so raku-mode will still work with .pm6 files!) and proceed from there; or
2. Begin with raku-mode being dependent on perl6-mode as its parent, then over time, migrate functionality until we can lose the dependency altogether.

My analysis is that there’s only one advantage in going for the derived-mode option, but it’s a huge one: it won’t immediately impact users before they’re ready for it to. Assuming the typical user will be working on legacy .pm6 and .rakumod files simultaneously in different projects for some time, this is a big win: it’s doubtful that any users want Emacs to behave differently in legacy and new projects.

But, as huge as this advantage is, it may be entirely undercut by an advantage of the hard cutover: users will be most familiar with their own configurations, and so if they must take action to continue to have editor support, they will know how to do so. That relieves us from having to include any migration code at all except for the defcustom variable’s renaming.

If it were a reasonably tractable problem to do the job of automatically migrating configurations, I’d say we should—we shouldn’t shove even a small burden onto all our users when we can avoid it, even if it requires substantial effort on our parts. But it isn’t “reasonably easy” to do even an 80% job. This is a problem with configuring an editor using a full programming language like elisp—other code like ours can’t safely modify it.

¹ Whether to preserve this repo’s history is another minor question that can be taken up later.

Perl 6 → Raku code migration

Do we want to include any code in raku-mode to assist in Perl 6 to Raku language migration? For instance, filename changing, fixing .perl calls, etc.?

I fully expect there to be one or more standalone migration tools (almost certainly implemented in Raku themselves), so I think the right answer here is to wait and see what tools develop, and if there are any holes that belong in the editor, or if it seems advantageous to support running the external tools inside the editor, we can make small enhancements to support this. (This isn’t much different from offering access to a linter or a prettifier like perltidy.)

[treyharris]

One more thought I had sleeping on it—not that I (or any of us) have been very responsive to bugs and enhancement requests of late, so it’s not like we need an excuse to continue benign neglect of the package—but is it better to get perl6-mode “ship-shape” before we start the renaming, or for the sake of reducing the impact on people with both potentially backwards-incompatible new code and a definitely impactful name-change, should we go ahead and freeze perl6-mode now unless/until the Raku name change is somehow abandoned and we’re sticking with Perl 6?

(No, this is not a reason to avoid work on issues; but we shouldn’t merge them into HEAD for the time being.)

[Ovid]

Note: the top-level ticket says "edited by Ovid". I accidentally clicked a checkbox. I unchecked it after I saw what I had done. I did not change the ticket. Sorry for the noise.

[treyharris]

@Ovid No worries, Curtis—I deleted them.

[matiaslina]

filename extensions mentioned in Raku/problem-solving#89—currently, .raku, .rakumod, and .rakutest, though .t will continue to be available and all legacy extensions like .pm6 will continue to be supported.

Marking this as done due to 4ed7c06 (support for .rakutest) and 282dd2c (support for .raku and .rakumod)

[matiaslina]

Changing the name of the library, and its functions, exposed variables, faces, keymaps, and hooks—and, where possible, creating aliases to the old ones.

The perl6/perl6-mode to Raku/raku-mode repo is already in place, so this item should be the next to work on the renaming process. There's two options proposed by @treyharris:

1. Do a hard cutover from perl6-mode by creating a new repo with source code cloned from this one,¹ and just globally string-replace raku for perl6, adding the new file extensions and shebang recognizer (adding, so raku-mode will still work with .pm6 files!) and proceed from there; or
2. Begin with raku-mode being dependent on perl6-mode as its parent, then over time, migrate functionality until we can lose the dependency altogether.

I think the best move is (1). IMO making raku-mode dependant on perl6-mode is a mistake considering:

• perl6-mode is already on MELPA and we should publish raku-mode as a separate package.
• Is not a huge codebase, so it's not that hard to replace all the perl6 strings.
• Maintaining a single major mode is easier than two.

Proposal

• Replace every occurrence from perl6 to raku.
• Make a (defalias 'perl6-function 'raku-function) where it makes sense.
• Keep recognizing old perl6 files as raku files (.pm6 for example).
• Keep perl6-mode on MELPA for a while and mention it on the README.

Any feedback on this would be great (It's ok?, Do we do something else?, There's something I'm missing? etc.)

[Altai-man]

Any feedback on this would be great (It's ok?, Do we do something else?, There's something I'm missing? etc.)

5 cents on this:

• Yes, please, publish a raku-mode package, while perl6-mode can be present there for people who are slow on migrating. If we have access (I think we do), you can set its status to "deprecated" and/or note in the description in some uppercase something like "This mode is obsolete, consider using raku-mode instead".
• Make a (defalias 'perl6-function 'raku-function) where it makes sense <- yes
• Keep recognizing old perl6 files as raku files (.pm6 for example) <- by all means. I would not consider dropping old filenames support in next, dunno, 5 years or something. And supporting them is cheap and easy (or must be this way), so.
• Keep perl6-mode on MELPA for a while and mention it on the README <- why not the other way around as suggested? What's the merit of mentioning "And you know, we have an obsolete pre-rename mode repo"? Or did I misunderstand you?

[matiaslina]

why not the other way around as suggested?

Just because this was the perl6-mode repo. https://github.com/perl6/perl6-mode redirects here. I didn't even think about linking this repo in the old one :p

We can mention raku-mode on the original repo that is linked in the readme and leave the readme here as is.

[Altai-man]

We can mention raku-mode on the original repo

Sadly enough, I am not sure we have access to this one, though you can try to contact the author directly asking for a write access.

Just because this was the perl6-mode repo. https://github.com/perl6/perl6-mode redirects here

I see, indeed, maybe this makes sense, but it'll probably be easier to think about it in terms of some actual changes, at least for me.

Anyway, as far as I know, this repo wants some love and maybe even a maintainer, so if you have any improvements on mind, don't hesitate to try them out, it will be very welcomed. Also, feel free to ask if there is anything that can help you.

[matiaslina]

Anyway, as far as I know, this repo wants some love and maybe even a maintainer, so if you have any improvements on mind, don't hesitate to try them out, it will be very welcomed

Agree with that. I don't have a lot of knowledge on elisp or emacs packages, but I'll try to keep an eye here checking issues that come up, be reviewer of pull request, etc.

Also, feel free to ask if there is anything that can help you.

Will have that in mind! The reviews are great so far.

[zakame]

Nice surprise on my MELPA sync today for my emacs, with raku-mode 🎉 thanks @matiaslina @Altai-man

For upgrading from perl6-mode, I'd suggest suggesting a (defalias 'perl6-mode 'raku-mode) in the docs, e.g. for use-package with quelpa to fetch from this repo directly:

;; Add Perl6 editing support
(use-package perl6-mode
  :preface (defalias 'perl6-mode 'raku-mode)
  :defer t
  :quelpa (perl6-mode :fetcher github :repo "perl6/perl6-mode"))

It might be worth doing this defalias directly in this repo's code too, perhaps if only to be consistent with the current MELPA packaging (at least until the package rename, at which point the perl6-mode package can just depend on raku-mode package.)

[matiaslina]

It might be worth doing this defalias directly in this repo's code too, perhaps if only to be consistent with the current MELPA packaging (at least until the package rename, at which point the perl6-mode package can just depend on raku-mode package.)

Agree with that. It's better than suggest to add the defalias in the config. A lot of people might miss that.

[zakame]

melpa/melpa@e9831cc now renames perl6-mode package to raku-mode. 🎉

[widefox]

I did the trivial changes to create the matching flycheck-raku , a couple of pull requests done.