Open treyharris opened 4 years ago
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.)
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.
@Ovid No worries, Curtis—I deleted them.
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 https://github.com/Raku/raku-mode/commit/4ed7c06294e319e9de653fdd91cc2ca5ee717399 (support for .rakutest
) and https://github.com/Raku/raku-mode/commit/282dd2c9e13200b0f4c2d50c0bd120831afe37ee (support for .raku
and .rakumod
)
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:
- 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
- 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.perl6
strings.perl6
to raku
.(defalias 'perl6-function 'raku-function)
where it makes sense..pm6
for example).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.)
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:
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
<- yesKeep 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?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.
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.
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.
Nice surprise on my MELPA sync today for my emacs, with raku-mode
:tada: 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.)
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.
https://github.com/melpa/melpa/commit/e9831cc66d9a9e6b6441e6a75d54ce57146571fd now renames perl6-mode
package to raku-mode
. :tada:
I did the trivial changes to create the matching flycheck-raku , a couple of pull requests done.
This issue is to discuss and track what may need doing for perl6/user-experience#19 and perl6/problem-solving#89 if the language name changes (most likely to Raku).
A non-exhaustive list of tasks:
.raku
,.rakumod
, and.rakutest
, though.t
will continue to be available and all legacy extensions like.pm6
will continue to be supported.A few questions for clarification:
MELPA
raku-mode
and let the last version ofperl6-mode
continue to live for some period?perl6-mode.el
, or a handler in a raku-mode library) in the distribution, or do we depend on theperl6-mode
package?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:
I think this leaves us with a big early decision:
raku
forperl6
, adding the new file extensions and shebang recognizer (adding, so raku-mode will still work with.pm6
files!) and proceed from there; orMy 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.
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.)