vim-perl/vim-perl

Support for Perl 5 in Vim

vim-perl

This is the aggregation of all the various Perl-related syntax and helper files for Perl 5.

For Perl 6, which is now named Raku, please see vim-raku.

Installation

You can install vim-perl using

• Pathogen and git submodules
• Vundle
• VAM
• vim-plug

They were all tested and work: please read the related documentation on the related sites.

The legacy method is to install just do a "make install" and you'll get the .vim files all installed in your ~/.vim directory.

Installing using vim-plug

In your .vimrc:

call plug#begin('~/.vim/plugged')

Plug 'vim-perl/vim-perl', { 'for': 'perl', 'do': 'make clean carp dancer highlight-all-pragmas moose test-more try-tiny' }

call plug#end()

Re-source your configuration, do PlugInstall, and you're done.

The do argument is optional, and can be used if you want to enable any of the optional sub-syntaxes.

The perl argument is also optional, and only required if you want to lazy-load the plugin only if dealing with Perl files.

Getting Help

Any bug reports/feature requests/patches should be directed to the vim-perl group.

When reporting bugs in the highlighting of items, please include an example file as well as a screenshot demonstrating the problem.

FAQ

Can you add highlighting for Moose, Try::Tiny, Test::More, SQL in strings, etc?

We have syntax "extensions" under the contrib/ directory; you can find custom highlighting for these sorts of things there. To enable any of them, just drop the relevant file in a after/syntax/perl directory visible to vim.

$ cp contrib/dancer.vim ~/.vim/after/syntax/perl/

You can also populate the local after/syntax/perl/ via make:

$ make dancer moose

$ ls after/syntax/perl
dancer.vim  moose.vim

Curly braces inside of regexes/strings are considered when I use %

(See also GH #86)

Vim itself only considers double quotes in this scenario; the matchit plugin, however, can deal with this scenario and vim-perl's files are set up to work with it should you choose to use it.

vim-perl's Issues

Perl 6: Zero width character class matches aren't recognised

Inside a rule <?[a..f]> is a zero-width match against a character class, which isn't detected by perl6.vim. Fixing it is a simple matter of changing line 826 from this:

\ start="\%(<[-!+]\?\)\@<=\["

To this:

\ start="\%(<[-!+?]\?\)\@<=\["

Including perl.vim in other syntexes

Hello!

First of all great thanks for your perl.vim and very useful syntax testing example. Testing with Text::VimColor made me fix few unobvious bugs in my syntax files.

I want to ask you if you could advise me how to solve problem with including perl.vim into other syntaxes.
Main problem is that perl.vim being included into cluster like
syn include @Perl syntax/perl.vim
behaves different: perlFunctionName overrides almost all statements (looks really irritatingly). Also perlElseIfError group marks any '\s+if' (not only else ... if ) as error.

At the moment I'm solving this problems just removing corresponding groups from cluster, like
syn cluster Perl remove=perlFunctionName,perlElseIfError

But loosing perlFunctionName makes syntax looks much poor.

I think this problems are related to contained flag appended to each top-level syntax element during include.
I will dig more to find roots of the problem, but maybe you as maintainer of vim-perl already know quick solution?
There's syntax example that describes the problem:
syntax/dummy.vim

if exists("b:current_syntax")·
    unlet b:current_syntax
endif

syn include @Perl syntax/perl.vim

syn region PerlInside keepend start=+^+hs=s end=+$+ contains=@Perl

let b:current_syntax = "dummy"

test.dummy

print 1;
foobar;
if (1) { 1 }
    if (1) { 1 }

Thank you for advance.

ftplugin/perl.vim - do not overwrite 'path'

ftplugin/perl.vim, line 63: The vim 'path' setting is clobbered; the whole path is replaced by Perl's @inc contents. Appending to 'path' seems more appropriate.

Also, b:undo_ftplugin should be extended to undo the 'path' setting.

I discussed these with Dan Sharp in the past, and he provided a patch, but it seems to have got lost.

Create automated test suite

How do we know we haven't broken coloring at any given point? We don't.

We need some sort of automated test suite that verifies the results of the color-coding.

My initial idea: Use the Perl Text::VimColor module to create HTML of a sample file and then verify the accuracy of it.

Bare blocks don't fold and neither do control statements if labels are put in front of them.

Just paste the code below into vim to see that Labels before loops do not fold properly.

Without a label the loop folds as it should, but if you put a label in front of the loop it doesn't fold.

LABEL: for (1..10) {
    print;
}

for (1..10) {
    print;
}

And

WHILE: while () {
    print;
}

while () {
    print;
}

This is also probably true for until and foreach as well.

Also, bare blocks do not fold such as...

{ # bare block
my $closure = 'closed';

    sub closure {
        # can still access $closure
        print "$closure\n";
    }
} # end of bare block

And if you put a LABEL: in front of bare blocks it doesn't work either.

BARE: { # bare block
my $closure = 'closed';

    sub closure {
        # can still access $closure
        print "$closure\n";
    }
} # end of bare block

If you think no one uses bare blocks, I have occasionally for closures and
limiting scope of some my variables. There is also this example copied out of
perlsyn implementing a switch.

SWITCH: {
if (/^abc/) { $abc = 1; last SWITCH; }
if (/^def/) { $def = 1; last SWITCH; }
if (/^xyz/) { $xyz = 1; last SWITCH; }
$nothing = 1;
}

syntax perl.vim: Issue with here-doc containing } and folding

Hi,

when activating folding with :let perl_fold = 1, fold detection for subs and a here-doc containing a '}' at the same indentation like the sub are conflicting.

sub f {
    print <<EOF ;
int my_c_func(void)
{
    return 0;
}
EOF

}

Now folding thinks, the sub ends at the brace before EOF, since it has the same indentation - this brings the highlighting for here-docs in trouble.

Unfortunately, I have no idea how this can be fixed easy. As far as I understand syntax highlighting, it seems not to be possible to use some kind of flag in syntax elements. Maybe vim manual "44.6 Following groups" could be helpful for this?

Consider handling embedded SQL in heredocs

Put this in .vim/after/syntax/perl.vim

runtime! syntax/sql.vim
unlet b:current_syntax
syntax include @Sql syntax/sql.vim
syntax region sqlSnip matchgroup=Snip start=+<<['"]SQL['"].;\s$+ end=+^\s*SQL$+ contains=@Sql

Incoporate some outside changes

http://use.perl.org/~Ovid/journal/38725

mauke has been maintaining a version of perl.vim for a few years. If you are the official maintainer now, I believe you should at least use his latest version as a base. It's much better than the one currently provided by vim. See http://www.vim.org/scripts/script.php?script_id=2300 [vim.org]

In addition, I noticed a perl6.vim in your repository. It seems to be an outdated version of the syntax file in the pugs repository. That file has seen vast amounts of improvements (by me) since then. You can find it at http://svn.pugscode.org/pugs/util/perl6.vim [pugscode.org]

escaped quotes don't seem to work quite right

Not sure when this started, but as of this morning, this doesn't highlight quite right:

$test = " this is a test: "test" -- how did we do?";

POD is still highlighted in __DATA__ and __END__ blocks

I could see this as being a positive, if you like your POD like Damian suggests it, or bad if not.

\& confuses the indentation

If you have this code:

#!/usr/bin/perl

use strict;
use warnings;

sub _do_nothing
{
}

sub hello
{
    my $args = shift;

    my $continue_cb = ($args->{'cont'} || \&_do_nothing);
}

And press "o" on the $continue_cb line then vim indents it at column 1, while it should be on column 4. This extends to other lines that are indented improperly after being written.

I'm using gvim-7.3.29 on Mandriva Linux Cooker on x86-32.

Set makeprg and errorformat

If makeprg and errorformat are set, you can use the ]c and [c commands to find syntax errors:

setlocal errorformat=%f:%l:%m
setlocal makeprg=perl\ -c\ %\ $*

'package' at the very beginning of a line in a heredoc causes vim to display the syntax coloring wrong.

In the example below, the line beginning with 'package' is highlighted like its package Some::Package; instead of being properly quoted inside a heredoc like it should be.

my $example = <<EOF;
quoted like it should be.
package except everything after this line, because it begins with package.
EOF

comment before opening brace of a sub is broken

Suppose you have this code:

sub foo # comment
{
print "Hi\n";
}

The "# comment" portion is not highlighted correctly.

The fix is merely adding perlComment to the appropriate nextGroup entry, I will submit a pull request referencing this issue.

// still treated as regex

// # colourised as a quote operator
//= # colourised as a quote operator followed by = ( which is coloured as a token )

'package' on the beginning of a line overrides pod formatting

Right now, it seems that if I have some pod text that has a line starting with 'package', then that line is highlighted like a package declaration, not like pod as it should be.

In case it makes a difference, I'm using:

let perl_include_pod = 1 
let perl_want_scope_in_variables = 1 
let perl_extended_vars = 1 
let perl_fold = 1 

Ship the test suite in the tarball

From Paul Howarth:

The "make check" facility is great but unfortunately the test suite is not included in the tarball and so can't be used without downloading test-thing.sh and the contents of the tests/ directory. Please consider adding these to the tarball in the next release.

Perl 6 files are slow to open

$> vim somefile.p6 # No filetype set to .p6

#!/usr/bin/perl6

 #lots of code here

 # vim: set ft=perl6

Save and open the file in vim. There's a noticeable delay in loading it.

Perl 5: Escaped closing delimiters in SQ strings look wrong

'foo \' bar'
q[foo \] bar]
q{foo \} bar}

The escape sequence will not be highlighted correctly (should have the same color as \\). perl6.vim does this right, though.

Allow new keywords (Devel::Declare)

There are vim scripts out there that allow for things like MooseX::Declare, but it would be nice to have this behavior configurable somehow maybe.

[perl6.vim] $m, opens a regex quote

For instance, in sub foo($m, $k) {...}, perl6.vim will switch to regexy highlighting at the $m and not switch back until the next comment in the code. Either $m should not be treated as a quote introducer, or, if that is not practical, simply forbidding , as a quote character would be sufficient for most purposes.

Arrow operator rendered differently in static vs. object methods

I would like to see the render be the same for both cases (or optionally different in the case of static methods).
Currently the coloring behavior is properly applied to the $foo->bar case, but not in the Foo->bar case.

Set equalprg=perltidy

If you press '=' you can format some text. You can use equalprg to do that:

setlocal equalprg=perltidy

Evally sub-regexes should be highlighted as normal perl code.

Ideally, the second half of this should be formatted differently depending on whether or not that final e is present, but I can understand this is a hard problem ;)

If you feel especially brave, this would be nice to work too:

Range of 1..3 gets colorized like "1." is part of a decimal number

1..3 comes out colored wrong. The .. should be seen as an operator.

Perl 6 boolean keywords

Highlight True, False and Bool.

Nested quoting and interpolation confuses the syntax highlighting

Example of braces in qq{} not being handled properly by gvim 7.3 perl syntax highlighting.

print qq{<a href="$h{var}">}, '$this_is_not_interpreted';

vim-perl Does Not Include xs.vim ftplugin and Syntax Highlighting Files.

At this time I don't really know C or XS, so I can't really help update them, but while digging around in vim's share directory I found files for XS, and noticed they're not included in this project, so I figured I'd let you know with this bug report. These files are both called xs.vim, and they're in the directories /usr/share/vim/vim72/{syntax,ftplugins}. Please consider adding them to this project, so anyone using XS in vim has working up to date syntax highlighting and ftplugin stuff.

Ship documentation

From Paul Howarth

Ideally, the htmldoc/ directory would be included in the tarball too, along with configure checks for the tools needed to build the documentation such that it all got built automatically where possible, and in the case of the manpages, installed too. But just including the htmldoc/ directory would be a good start so that people could build and install the docs themselves if they wanted them.

keywordprg should also look for module documentation

http://use.perl.org/~Ovid/journal/35469

To look up module names, iskeyword needs to include ':'. isfname is not used by keywordprg.
Perhaps 'K' should be mapped to a function that handles this instead.

If a regex using an alternate delimiter finishes with a $ sign, perl.vim thinks it is a variable.

https://bugs.launchpad.net/ubuntu/+source/vim/+bug/494124

m[foobar$]
m#foobar$#

will higlight $] and $# as a variable. The real impact is that it doesn't perceive the regex as terminated, and highlight the rest of the document accordingly, until it reach a suitable delimiter.

I use Ubuntu 9.10 netbook remix
Vim : VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Sep 21 2009 11:22:49)
Included patches: 1-245

Named regex hash is not highlighted %+

%+ is not higlighted but $+ is.

indent/perl.vim: pass to Vim distribution and fix last change date

Just to note that the current Windows Vim distribution (ftp://ftp.vim.org/pub/vim/pc/gvim73_46.exe) doesn't include the latest version of indent/perl.vim. The version in the distribution still has the problem with backslashes in strings. Can the latest version be passed to Bram, please?

Also, the last change date in the header comment doesn't appear to have been updated since the backslash problem was fixed. Can it be updated, please?

Thanks,

Jon.

mason syntax highlighting has problems

It includes the perl.vim syntax and, with the latest version, a lot of perl keywords (e.g. my, local, elseif, etc.) are highlighted as perlFunctionName instead of their proper highlight group. The syntax/perl.vim from vim 7.3 seems to work fine.

Heredoc Inside @{ ... } Missed

This heredoc won't color correctly:

print @{ $dbh->selectrow_arrayref(<<SQL) };
Here document
SQL

This is especially annoying when the content of the heredoc is misinterpreted as Perl code. An example is:

print @{ $dbh->selectrow_arrayref(<<SQL) };
SELECT s.site_hum_id
  FROM site_inst s
SQL

The `s.' in the line above is thought to be the start of s/// and quoting is really messed up after that.

I don't know when this changed. It used to work correctly (modulo the trailing stuff in the line with the <<SQL). I am using vim 7.3 as packaged for Fedora 14:

vim-common-7.3.056-1.fc14.x86_64
vim-filesystem-7.3.056-1.fc14.x86_64
vim-X11-7.3.056-1.fc14.x86_64
vim-enhanced-7.3.056-1.fc14.x86_64
vim-minimal-7.3.056-1.fc14.x86_64

I found that, if I removed a line from perl.vim, it is all better now. I suspect there is something else that will fail with my change, but the tests in the latest tree all pass with my change.

Here's the changes I made:

garry@vfr$ diff -u t_source/perl/advanced.t.orig t_source/perl/advanced.t
--- t_source/perl/advanced.t.orig       2011-02-20 15:00:10.008956924 -0500
+++ t_source/perl/advanced.t    2011-02-20 15:03:34.414913825 -0500
@@ -40,6 +40,9 @@
 print <<'EOF' if $true;
 Here document
 EOF
+print @{ $dbh->selectrow_arrayref(<<SQL) };
+Here document
+SQL

 # Here documents finishing with an empty line. Note the Error colour because of
 # the line with only a space in it.
garry@vfr$ diff -u t_source/perl/advanced.t.html.orig t_source/perl/advanced.t.html
--- t_source/perl/advanced.t.html.orig  2011-02-20 15:08:01.755867238 -0500
+++ t_source/perl/advanced.t.html       2011-02-20 15:06:16.423488985 -0500
@@ -48,6 +48,9 @@
 <span class="synStatement">print</span> <span class="synString">&lt;&lt;'EOF' if $true;</span>
 <span class="synString">Here document</span>
 <span class="synString">EOF</span>
+<span class="synStatement">print</span> @{ <span class="synIdentifier">$dbh-&gt;selectrow_arrayref</span>(<span class="synString">&lt;&lt;SQL) };</span>
+<span class="synString">Here document</span>
+<span class="synString">SQL</span>

 <span class="synComment"># Here documents finishing with an empty line. Note the Error colour because of</span>
 <span class="synComment"># the line with only a space in it.</span>
garry@vfr$ diff -u syntax/perl.vim.orig syntax/perl.vim
--- syntax/perl.vim.orig        2011-02-20 15:05:40.212890058 -0500
+++ syntax/perl.vim     2011-02-20 15:06:02.307696201 -0500
@@ -147,7 +147,6 @@
   syn region perlArrow         matchgroup=perlArrow start="->\s*{" end="}" contains=@perlExpr nextgroup=perlVarMember,perlVarSimpleMember,perlMethod contained
   syn match  perlArrow         "->\s*{\s*\I\i*\s*}" contains=perlVarSimpleMemberName nextgroup=perlVarMember,perlVarSimpleMember,perlMethod contained
   syn region perlArrow         matchgroup=perlArrow start="->\s*\$*\I\i*\s*(" end=")" contains=@perlExpr nextgroup=perlVarMember,perlVarSimpleMember,perlMethod contained
-  syn region perlVarBlock      matchgroup=perlVarPlain start="\%($#\|[$@]\)\$*{" skip="\\}" end="}" contains=@perlExpr nextgroup=perlVarMember,perlVarSimpleMember,perlMethod
   syn region perlVarBlock2     matchgroup=perlVarPlain start="[%&*]\$*{" skip="\\}" end="}" contains=@perlExpr nextgroup=perlVarMember,perlVarSimpleMember,perlMethod
   syn match  perlVarPlain2     "[%&*]\$*{\I\i*}" nextgroup=perlVarMember,perlVarSimpleMember,perlMethod
   syn match  perlVarPlain      "\%(\$#\|[@$]\)\$*{\I\i*}" nextgroup=perlVarMember,perlVarSimpleMember,perlMethod
garry@vfr$

syntax/perl.vim -- not folding subs

To reproduce:

test.pl contains:

sub testsub
{
    my @args = @_;
    print "in testsub\n";
    return 1;
}
print <<EOF;
one
two
EOF

Execute the following:

vim -u NONE -U NONE
:set nocp
:let perl_fold=1
:syntax on
:set fdc=2
:e test.pl

The "testsub" block is not foldable, while the here document is.

The fold syntax items are defined:

:syn list perlSubFold
--- Syntax items ---
perlSubFold      xxx start=/^\z(\s*\)\<sub\>.*[^};]$/ end=/^\z1}\s*\%(#.*\)\=$/  keepend transparent fold
                start=/^\z(\s*\)\<\%(BEGIN\|END\|CHECK\|INIT\|UNITCHECK\)\>.*[^};]$/ end=/^\z1}\s*$/  keepend transparent fold

I see this problem in both Vim 7.2.441 and 7.3a; they both appear to have the latest syntax/perl.vim file. Unfortunately I don't really have an idea of when this broke, because usually I use marker based folding in my Perl files.

Don't highlight ending heredoc markers in POD blocks

I have the following chunk of code:

=for when we get switching of instances working

    my $sql = <<'HERE';
        select ....
HERE

    my $row = sqldo_hashref( $sql ... );

=cut

and the closing HERE is highlighted. It shouldn't be, because it's all comment in the POD.

[perl6.vim] traling comma causes mis-highlight

This piece of code makes perl6.vim freak out:

use v6;
my $x = [1, 2,
@s, # this trailing quote causes the
# next multi sub to be hilighted as a
# quote (not as a declaration)
];

multi sub svg-dump($x) {
}

[perl6.vim] Improper highlighting after lines with odd number of quotes

Vim syntax highlighting is not correct with lines after those containing odd number of quotes (single, in this case)

Here's a link to an example:
https://github.com/masak/yapsi/blob/master/lib/Yapsi.pm#L785

PS: I currently work around this by inserting another single quote on the same line inside a comment, like so # '

Add instructions for patching to each file

Add something to each file that says how to make patches. Otherwise, people email their changes to Bram, and he doesn't need the noise.

Improve Perl 6 detection

.p6 should be seen as Perl 6. Also .nqp. And maybe strengthen the sniffing for /^use v6;/

Improper syntax highlighting with heredocs

If I have something like this:

my $sth = $dbh->prepare(<<'END_SQL', undef, $foo, $bar);
select
    something
from
    somewhere
where
    something_else = 1
END_SQL

Then everything on the 'prepare' line after <<'END_SQL' gets highlighted as though it was part of the heredoc, even though perl is smart enough to know that the heredoc actually starts on the next line. Ideally, I'd like to see the <<'END_SQL' get highlighted as a string, and then the rest of the line highlighted normally, and then the actual contents of the heredoc highlighted as a string again. I looked at the part of the syntax file that implements this, but it doesn't seem super clear to me how to do this.

Also, as a major bonus, it would be cool if we could highlight any whitespace on the line that ends the heredoc as a syntax error (or at least trailing whitespace). That can cause exceptionally confusing errors for the uninitiated when using heredocs and it would be cool if vim could help you fix it.

updated xs syntax file

It looks like this is more up-to-date: http://www.profvince.com/perl/xs.vim

switch to pod.vim for pod sections

It's pretty darn common to interleave pods with code. I wish the pods would get highlighted as pods instead of comments. I believe it's possible to switch to another syntax style inside areas of a file. If it is possible, I'd really like to see the pod syntax for pods in a perl file.

Autoenable pod.vim

Turn on POD formatting if the user has syntax/pod.vim installed.

[perl6.vim] Variables named token et al. can trigger regex highlighting.

A variable named regex, rule or token can trigger regex highlighting. A short example is this: if $token eq $bar { say "hello world!" }

I've fixed this locally (I wish I could attach files to these issues) by changing the regex on line 760 of perl6.vim to: "%(<%(regex|rule|token)@<!%([$%@&].?)\s+)@<=\K%(\k|[-']\K@=)*" (adding a look-behind making sure it won't match before a sigil and optional twigil).

ftplugin/perl.vim system calls 'shellxquote' logic too specific

ftplugin/perl.vim uses
if &shellxquote != '"'
let perlpath = system('perl -e "print join(q/,/,@inc)"')
else
let perlpath = system("perl -e 'print join(q/,/,@inc)'")
endif

This fails if shellxquote is empty and the shell doesn't use double quotes. E.g. my current settings:

set shell=/usr/bin/rc
set shellcmdflag=-c\ eval\ $*
set shellxquote=

The second branch with single quotes around the print statement would work just fine for my case but it won't get chosen because my shellxquote is empty.

I understand rc may be too non-standard to accommodate. Still it took me some time to track down why loading .pl files suddenly failed with E484's. Maybe it could fail a little more gracefully.

Get perl6.vim into vim

The perl.vim is effectively perl5.vim. Perl 6 is going to be different enough that I think we probably want to have perl6.vim be a separate file.

Get this perl6.vim file into vim. Send it to Bram.

qw highlighting misses some forms of legal punctuation

It recently occured to me that I was formatting my version line with extra spacing to avoid an error in vim's syntax highlighting with the qw construct.
my version->new( qw$ Revision $ ); # note extra space at the end between $ and )

This is because otherwise the highlighter would highlight the $) as a variable, when the $ is actually part of the qw.

There are some other punctiona marks as well, I tested a random selection of ones. As well as a couple that any developer using ought to be shot for. Please note the yellow color is used to represent strings in this theme. Light blue variables, and dark cyan "other".

Differentiate between interpolated and non-interpolated strings

Is it possible to modify the perl.vim syntax to support different highlights for interpolated and non-interpolated strings? I think it'd be a good extension given that the two types of strings can have "radically" different behavior and some people would prefer to use single quotes whenever possible. This change could help facilitate this behavior. Perhaps via a setting.

I've made some crude hacks of the file myself to permit it but I'm not very familiar with vim's syntax highlighting grammar and it might make the author's eyes bleed if they were to see it.
So here is an official request!

Thanks.