Is anyone taking care of this?

[JJ]

it's lately failing in Atom, and there's been no change for the last two years. Also, 45 issues. Anyone can help here?

[AlexDaniel]

At the time it was very well maintained by @samcv.

[samcv]

It would be good if someone could take up the reins on this. I have a pretty good description on how to start hacking on this here: https://github.com/perl6/atom-language-perl6/blob/master/CONTRIBUTING.md

Maybe I should do a release since there have been some PR accepted since the last release.

[2colours]

It seems that this package is used by the new docs site. I wouldn't have paid attention if it worked but something went wrong and then I had to take a look.

As we know, Atom is getting frozen. However, if this package is still in use by the new docs site and is gonna stay - I can't see a quick replacement for one - we still need to plan ahead.

Since I want to work with the docs site, I'm willing to get to know this package better.

However(?), my first step would be to remove all Coffeescript in favor of plain Javascript. I don't really know Coffeescript myself and things really didn't go in favor of Coffeescript in the last 6-7 years. It's much harder to find contributors with the intersection of Raku+Coffeescript knowledge than Raku+JS knowledge. Modern Javascript issued several inconveniences that led to the invention of Coffeescript in the first place and they are well available in Node by 2022. This code will run at the backend so Javascript version won't really be an issue anyway.

I would like to see if there is anyone out there who cares to adopt my eventual modifications in case. Nobody likes to work for nothing. :P

[samcv]

@2colours I am willing to accept any commits converting from Coffeescript to JavaScript.

What are you saying about Atom being frozen? Can you elaborate/link info about that?

In addition, this Atom module is also used for highlighting on Gitlab itself, so if Atom is being frozen then I am curious. I guess Gitlab would then still use this for highlighing.

[Xliff]

@samcv: Looks like Github is sunsetting Atom for Microsoft Visual Studio Code. You can find secondary validation from this article on the subject.

I have no information on whether modules for Atom will work for VCS, however I did find some instructions for porting Atom packages to VSCode.

[raiph]

Quoting from the article Xliff linked:

JUN 10, 2022: GitHub is giving six months' notice of Atom being discontinued to allow its users sufficient time to build their workflows elsewhere. On December 15, 2022, all Atom repositories will be archived. So it's not the end just yet, but it's close. In the time leading up to this date, GitHub will push reminders of the impending doom of its text editor just so you don't forget.

So, what's next? The logical (and Microsoft-expected) move is that folks will simply move over to Visual Studio Code. As with Atom, it's completely cross-platform and open-source, and there are versions out there without the Microsoft telemetry if that's the part that puts you off. Atom can of course be forked before its demise, but whether anyone can keep it alive for the long term is a mystery. Alternatively, Jetbrains Fleet looks pretty interesting, albeit as yet not publicly available.

[Xliff]

@raiph, she did ask for more info on the matter. Better late than never!

[raiph]

@Xliff

Ah. I just cut/pasted the date from the article as an afterthought to help readers understand the Dec date it mentions really is the drop dead date without needing to click through to the article. I see in retrospect it could be taken the wrong way. I've now edited my comment to try eliminate misinterpretation. Thanks for the heads up.

❤ to all!

[samcv]

Thanks @raiph . So it seems this needs to be ported to Visual Studio code.

Years ago I looked into the situation. It didn't seem like they were incompatible, but had some differences in packaging, maybe some other things, it has been a while.

Needs to be done:

• Module should be ported to Visual Studio Code
• Ensure that Github highlighting will not be affected, and can get updates with the new version VSC module
• Potentially: publish multiple versions, one for VSC and and another potentially for Github highlighting (just speculation, could be we can switch to a VSC version module).

Followup:

• After work I am going to look into the Github highlighter situation, and refresh myself on that, as well as VSC highlighter situation. I will get back to everyone on what I think a good way forward, since this project is being used in 3 places currently (docs, github, and Atom).

[2colours]

For what it's worth: an LSP plugin has been created for YAPC (if I recall it correctly) this year. I think, for IDE support, that seems to be the safe bet: flexible, portable and you know, "hip 'n' cool" in general. Many people will first ask: "okay, what about IDE support? Is there an LSP?". I think somebody who knows the parsing/compilation process good enough, could be a great help to that project, and it's really a very visible thing.

Having said that, I'm not sure how much an LSP server can complement all the uses of this more conventional, static grammar-based package, like generating highlighted HTML in a fast and lightweight way. So I think even though this is also not a supplement for the LSP, there are still reasons to plan forward and any work on this is very appreciated! :)

[samcv]

Thanks @2colours, you beat my post. I had looked into this and did find that VSC LSP plugin too, which actually includes a highlighter taken from this repo. I haven't inspected all the code, but I believe it uses the grammar from this repo for the highlighting, while using LSP for other functions.

It also looks like there shouldn't be any compatibility issues with making this a VSC module. Maybe we can generate both an Atom and VSC module from this repo? I am not sure the best way to do this, but would prefer not to get rid of the issue tracker. Anyone have any thoughts?

@bscan seems to have created the LSP for VSC. Maybe you can say your thoughts as you have setup highlighting on VSC based on this repo. IMO there should be a separate VSC module for highlighting Raku, then the LSP could always depend on it. Then we have Github and docs.raku.org rely on the VSC module's grammar as well.

P.S.

Here is some references the Linguist repo has to this repo/grammar. This is what Github uses to highlight, so any changes should keep that in mind (plus ensure docs.raku.org also stays working).

• Github highlighting still references the correct bits
• Pod 6 https://github.com/github/linguist/blob/35159eef9aec4c5d0171a5bddf93a0f199e9724c/lib/linguist/languages.yml#L5001-L5011
• Raku https://github.com/github/linguist/blob/35159eef9aec4c5d0171a5bddf93a0f199e9724c/lib/linguist/languages.yml#L5495-L5523

[bscan]

Hi All, the Raku Navigator extension for vscode includes the language server, the syntax highlighting converted from this repo, the file extension mappings, the language configuration, and an icon. Ideally vscode would include everything except for the language server by default. It currently still includes support for "Perl 6" by default based on an older tmBundle, which can trip people up. Even with the Raku extension installed, some files will show as "Perl 6" and others will show as "Raku" depending on the file extension. The language server however will run on both of the language types.

I assume the easiest way to fix this would be to submit pull requests against the vscode repo to update the syntax to the latest version and change the name perl6 -> raku. Assuming they accept it, I would then remove those components from the Language Server extension.

Language Configuration: https://github.com/microsoft/vscode/blob/main/extensions/perl/perl6.language-configuration.json Syntax: https://github.com/microsoft/vscode/blob/main/extensions/perl/syntaxes/perl6.tmLanguage.json

Maybe we can generate both an Atom and VSC module from this repo?

Given the impending deprecation of Atom, I don't think maintaining an Atom-specific module is necessary anymore. Renaming this repo to something generic and updating the formats to be more vscode-compatible (e.g. .cson -> .json) is probably sufficient.

I'm happy to help out as well. Thanks!

[bscan]

Another thought after looking into this more: it's possible that the vscode maintainers may not be interested in having syntax highlighting for Raku by default. Currently, you need an extension to get syntax highlighting for fairly popular languages including: Scala, Kotlin, COBOL, Fortran, Haskell, Erlang, Lisp, and Scheme. I believe it would be a big win for vscode to simply remove the Perl 6 language identification. Then when anyone opens a .pm6 or .raku file, vscode will automatically prompt the user to download the Raku extension similar to how it works for those other languages. One advantage of this setup is the ability to get fixes out to users more quickly since we would not need to go through the vscode pull request process. In that case, any format is fine as long as we can post-process it into a vscode compatible .json file. Anyone have a preference between asking vscode to support Raku highlighting natively vs having the Raku community maintain an extension? In either case, it would get rid of the "Perl 6" name and old highlighting package.

[2colours]

@bscan I agree with you; it would be the best to get rid of this "inversion of control" that there is a sorta hardcoded VScode highlighter that the community can't maintain that well...

I wonder if we have a good place for these ideas though. I feel they exceed the issue of this particular repo.

By the way, I keep in mind to migrate to vanilla JS (maybe TS later on?), it's just my top Raku priority at the moment is to revive the Ddt module. There is just too much to do 😅

[bscan]

I filed this ticket, let's see where it goes: https://github.com/microsoft/vscode/issues/168319

[bscan]

The vscode team responded and is interested in keeping syntax highlighting bundled. I think we should point them to this repo, while making this repo a more generic location focused on tracking the grammar development, and not tied to any particular editor. This is also useful since Github/linguist is already tracking this repo.

[2colours]

https://github.com/2colours/Raku-highlighter

For what it's worth: I have been working on a fork. My goal is to switch/to remove Coffeescript (including CSON) altogether, and then do a PR with that. The outcome should generate functionally identical tmLanguage.json files from functionally identical - haven't completely decided but probably plain raku files - compared to the original CSON files.

[bscan]

@2colours, nice! Looks great already. I'd love for your changes to end up in vscode natively to avoid the confusion between the perl6 and raku grammars. Let me know if there's anything I can do to help.

In the meantime, I'm also interested in the raku.regex.tmLanguage.json and raku.quoting.tmLanguage.json files. Currently, my vscode Raku extension ( https://github.com/bscan/RakuNavigator/tree/master/syntaxes ) only contains the primary raku.tmLanguage.json syntax highlighting and does not include regex or quote highlighting.

[2colours]

Well, for the time being, I'm taking care of this. Either way, this issue digressed a lot; I think it's time to close it for now.