raku / raku-mode Goto Github PK

This error seems to happen if you have a multi line block following a closing curly brace.

To reproduce:

{} {
<press tab here>
}

The backtrace for this error seems to be the same SMIE functions called over and over again

Continuing discussion from melpa/melpa#4984, let me suggest a couple things regarding how do deal with it, in increasing difficulty:

• Remove nqp-mode as it currently stands, being a duplicate of perl6-mode. Mode detection for *.nqp files is done in perl6-detect.el, which means that even current perl6-mode users are not using nqp-mode by default (they'll have to override that in their own auto-mode-alist configs.)
• Make nqp-mode a subset of perl6-mode (a parallel to NQP being a subset of Perl 6,) having the latter mode defined using define-derived-mode. Currently perl6-mode itself (as well as nqp-mode, being a duplicate) derives from prog-mode, so if we choose to keep nqp-mode for later development, then we can keep the nqp- and perl6- bits in separate files.

What do you think?

As far as I can tell, the closest Raku semantic cousin to Perl's __DATA__ marker is =finish. As per the REPL:

> __DATA__
===SORRY!=== Error while compiling:
Unsupported use of __DATA__ as start of data.  In Raku please use: the
=finish pod marker and $=finish to read.
------> __DATA__⏏<EOL>

When I type __DATA__ in a *.pl file I'm editing in emacs, the item is recognized and the color and behavior of the text following it is identical to that of a multi-line comment (no special indentation, recognized keywords, etc.).

I think it would be helpful to have something analogous in raku-mode whenever =finish is encountered. Currently, it doesn't have much of an effect at all: indentation stays in place, keywords that I might place accidentally in the $=finish text are still colorized, etc.

Would this make for a good enhancement of the mode?

@perl6/org-admins: I put a call out on IRC #perl6 but since that won't get everyone, I'll repeat my request here:

...It seems ilke the canonical Emacs perl6-mode has been abandoned (9 months of author inattentiveness), but the fork under the perl6/ GitHub project can't be made official for Emacs packaging because it's a fork. I've made a tasklist on GitHub (#11) to track this, and right now we're still in step no. 2—wait a week to see if the original author returns after informing him of our intentions to take over maintenance—but assuming he doesn't respond or blesses the transfer, we'll need an Owner of the GitHub Perl 6 project to handle working with GitHub support to break the fork and move over the open issues. (This is something they do, but only in a support-ticket context, there's no interface or API for it.)

I'd take care of it—I've done this before in other projects on GitHub—but I'm not an Owner so can't. Would one of you be willing to help me with this next week (that is, the week beginning Sunday 14 May)?

Again, since I've done this before, I can lead you through it. I just don't have the access rights to do it here. If you can volunteer, please reply and/or assign yourself this issue.

Thanks!

This happens after adding this to my config

(define-auto-insert
	'("\\.rakumod\\'" . "Raku module skeleton")
	'raku-module-skeleton)
(define-auto-insert
	'("\\.raku\\'" . "Raku script skeleton")
	'raku-script-skeleton)

This is GNU Emacs 27.2 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.31, cairo version 1.17.4)
of 2023-05-10

I think perl6-mode should be used for nqp files as well.

Type:

sub f {<RET>}

Expect:

sub f {
}

Get:

sub f {
	}

will propose a layout later

Check out Cask and make it work or elminate it altogether.

consecutive lines inside HERE blocks react unexpectedly to tabbing

Currently, blocks of Pod are highlighted as code, rather than comments. Consider the following example, which I would expect to be uniformly coloured the same as a comment:

=begin pod

=head1 This is a head.

Note: For testing purposes, "here is a string".

=end pod

Being able to distinguish Pod from actual code would help orientation in code documented with Pod.

While testing regexes using emacs I found the following:

my $m = rx /\d ** 2 <?{ 1 <= $/ <= 12 }>/;

then all the text is colored like inside a string, I need to finish the line with #>> in order to finish the two opened <
I added the captures to better view of the problem:

Given the code

sub taglib-file-new(Str $filename --> File) is native(taglib) is symbol('taglib_file_new') is export(:ALL) { * }

I want to format it as

sub taglib-file-new(Str $filename --> File) 
   is native(taglib) is symbol('taglib_file_new') is export(:ALL) { * }

But raku-mode wants to format it as

sub taglib-file-new(Str $filename --> File) 
is native(taglib) is symbol('taglib_file_new') is export(:ALL) { * }

If I write the following (from Moritz Lentz's book)

        my $sth = self!db.prepare(qq:to/SELECT/);
        SELECT exitcode, timed_out, output
                                        FROM $table
                                        WHERE jobname = ?
                                        ORDER BY executed DESC
                                        LIMIT $count
                                        SELECT

perl6-mode does not recognize the here-doc and seams to indent and highlight its contents as perl6 code.

Greetings,

With something like this:

$cmd = qq/kubectl patch secret $secret-name -n datahub --kubeconfig $kube-config-file \'$patch \' /;

After the escaped single quote near the end, the syntax highlighter gets confused and colors everything as a string after that.

Thanks
pj

Escaped double quotes are still highlighted as quotes
I need to add quote in comment to fix back highlighting.

Example -- everything after itvalue definition get highlighted in one color

grammar SomeGrammar {
 token itvalue { \" <-[\"]>+? \" } 
 token somevalue { \" <-[\"]>+? \" } 
 token another token { nothingSpecial } 
}
}

While this works fine

grammar SomeGrammar {
 token itvalue { \" <-[\"]>+? \" } # "
 token somevalue { \" <-[\"]>+? \" } # "
 token another token { nothingSpecial } 
}

The contents of a heredoc are highlighted as if they were code, instead of a string.
See attached screenshot.

when open file rakudo src file: ~/rakudo/src/Perl6/Actions.nqp, can't reslove signle quote comment.

at line 9846 of the file : ~/rakudo/src/Perl6/Actions.nqp

The project doesn't have any git tag, so MELPA will never publish the mode in MELPA stable. Could you add a git tag to the repo?.

With the given code, possible ways to indent it are:

my $resp = await Cro::HTTP::Client.patch: $url, :$headers,
           :%body, content-type => ‘application/json’;

Or:

my $resp = await Cro::HTTP::Client.patch: $url, :$headers,
                                          :%body, content-type => ‘application/json’;

However, perl6-mode does this:

my $resp = await Cro::HTTP::Client.patch: $url, :$headers,
:%body, content-type => ‘application/json’;

This ticket is inspired by reddit comments.

Example: you type <=, it should automatically replaces it with ≤. Obviously, make it possible to turn that feature off, but perhaps consider having it enabled by default.

List of non-texas ops: https://docs.perl6.org/language/unicode_texas

Sister tickets:

• atom-language-perl6
• vim-perl6

See these lines:

Only the first autoload call beneath each ;;;###autoload is being indexed by Emacs' autoloader. Specifically, the resulting raku-mode-autoloads.el looks like this:

;;;### (autoloads nil "raku-detect" "raku-detect.el" (0 0 0 0))
;;; Generated autoloads from raku-detect.el

(add-to-list 'interpreter-mode-alist '("perl6" . raku-mode))

(add-to-list 'auto-mode-alist '("\\.p[lm]?6\\'" . raku-mode))

(defconst raku-magic-pattern (rx line-start (0+ space) (or (and "use" (1+ space) "v6") (and (opt (and (or "my" "our") (1+ space))) (or "module" "class" "role" "grammar" "enum" "slang" "subset")))))

(autoload 'raku-magic-matcher "raku-detect" "<snip>" nil nil)

(add-to-list 'magic-mode-alist '(raku-magic-matcher . raku-mode))

;;;***

To correct this, either prefix each line with ;;;###autoload\n or ;;;###autoload , e.g.

;;;###autoload (add-to-list 'interpreter-mode-alist '("perl6" . raku-mode))
;;;###autoload (add-to-list 'interpreter-mode-alist '("raku" . raku-mode))

;;;###autoload (add-to-list 'auto-mode-alist '("\\.p[lm]?6\\'" . raku-mode))
;;;###autoload (add-to-list 'auto-mode-alist '("\\.nqp\\'"     . raku-mode))
;;;###autoload (add-to-list 'auto-mode-alist '("\\.raku\\'"    . raku-mode))
;;;###autoload (add-to-list 'auto-mode-alist '("\\.rakumod\\'" . raku-mode))
;;;###autoload (add-to-list 'auto-mode-alist '("\\.rakutest\\'" . raku-mode))

Or, alternatively:

;;;###autoload
(add-to-list 'interpreter-mode-alist '("perl6\\|raku" . raku-mode))

;;;###autoload
(add-to-list 'auto-mode-alist '("\\.p[lm]?6\\'" . raku-mode))
;;;###autoload
(add-to-list 'auto-mode-alist '("\\.nqp\\'" . raku-mode))
;;;###autoload
(add-to-list 'auto-mode-alist '("\\.raku\\(?:mod\\|test\\)?\\'" . raku-mode))

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 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.)

Installation from MELPA doesn't work
I got this error message

package-install-from-archive: https://melpa.org/packages/perl6-mode-20161228.430.tar: Not found

I think you need to update melpa with the latest version

The readme links to https://github.com/widefox/flycheck-raku for flycheck-raku when the current upstream is https://github.com/Raku/flycheck-raku

See https://github.com/widefox/flycheck-raku for details.

The original mode from which this has been forked seems to have been abandoned. This is problematic, because updates are not being reflected in MELPA, from where most Emacs users get packages.

This is unsustainable as it could eventually block adoption of Perl 6 by Emacs users. It also seems like the Perl 6 GitHub project is the right place to be the focus of development for the Emacs mode, since it's historically been one of the most popular editors for Perl programmers.

This is a punch list for what's required to get this repo to be the "official" one:

• Make one more attempt to contact @hinrik by dropping an issue in the upstream's issues pointing at this issue
• Wait 1 week for a response
• Snapshot the network graph, since we need to inform contributors to any other forks once this has been completed
• Ask an Owner of the Perl 6 project to open a support issue with GitHub asking them to break the fork, so that this repo becomes a canonical one (this is required for MELPA to accept this repo as the new canonical source) — being tracked in #12
• Verify support issue has been opened
• Wait for GitHub support to break the fork
• Edit the perl6-mode recipe to point here and submit a pull request (linked back here)
• Verify the package is on MELPA
• Inform any previous forks identified in the prior step
• Go through the old upstream's issues and see if any still apply; if so, open them here as new issues and reference them in the old

I'd like to hear comments on this plan. I'm comfortable taking care of all the steps, and will also create projects and milestones in this project.

I will begin with contacting @hinrik—since this is a necessary step regardless of the plan—seeking his response by 1 week from now, Sun 14 May 2007.

I'm learning raku followint THinking in raku and suing emacs raku-mode. until now all things are going well but I get this problem. I hope that can explain how to reproduce it:

I have the following raku script:

subset Positive-Integer of Int where { $_ > 0}

multi ackermann(0, Positive-Integer $n) {
    $n + 1;
}

multi ackermann(Positive-Integer $m, 0) {
    ackermann $m - 1, 1;
}

multi ackermann(Positive-Integer $m, Positive-Integer $n) {
    ackermann $m - 1, ackermann $m, $n - 1;
}

say ackermann 3, 4;

when I execute it on bash console, or using emacs compile I get the following:

-*- mode: compilation; default-directory: "~/learn/raku/trabajando-en-piensa-en-raku/" -*-
Compilation started at Mon Sep 14 17:47:26

raku ackermann.raku 
125

Compilation finished at Mon Sep 14 17:47:26

But when I send the code with C-c C-r or sending the whole buffer to the reple, I get this error

> > (Positive-Integer)
> > * * &ackermann
> > * * &ackermann
> > * * &ackermann
> > Cannot resolve caller ackermann(2, 1); none of these signatures match:
    (0, Int $n where { ... })
    (Int $m where { ... }, 0)
  in sub ackermann at <unknown file> line 3
  in sub ackermann at <unknown file> line 3
  in sub ackermann at <unknown file> line 3
  in sub ackermann at <unknown file> line 3
  in sub ackermann at <unknown file> line 3
  in block <unit> at <unknown file> line 2

I also opened a question on stackoverflow and the problem seems the way that I evaluated this

From the Emacs-devel mailing list:

Why are so many great packages not trying to get included in GNU Emacs?

I think it may be worth considering submitting raku-mode for inclusion in ELPA. To do so would require the following:

• Filling in some paperwork for copyright transmission to the FSF.
• Sending an email with a link to the Github repo asking for inclusion.
• Maybe some code cleanup if they ask for it.

The benefit would be that users could install raku mode without having to add MELPA to the Emacs package archives (although as of the time of writing there are a lot of packages not on ELPA, so I believe most users will have MELPA enabled anyway).

I sought help from the emacs mailing list and found out the sort option has to be done by the user through the built-in customizatio process. In this case I did

M-x customize-variable RET imenu-sort-order

and set the alpha sort and saved it for furure sessions.

Works as desired--problem solved!

Closing issue.

As far as I can tell, the repo from which this was forked is still that which is downloaded in melpa.

Are there plans to deploy this fork instead?

I see there was a long gap until two recent commits re. colours, and I'm not intimately familiar with Raku development but I know there's been active work in that time at least on the internals. So, is this mode still accurate for the version of Raku available today?

@AlexDaniel You asked me in Raku/doc#2904 if I needed any other rights, and I need admin rights on this repo as well. Thanks!