petdance / vim-perl

There are some things that I think should first be addressed.

• Filetype detection. I've started on this in my fork, but I haven't gotten it perfect yet.

• Iron out some bugs. There are some odd bugs that show up when certain syntax is involved. I can find some files in the Perl 6 test suite which are prone to trigger it. What happens is that the highlighting will look completely off until the cursor travels over the element that's causing the trouble. A related problem is that doing anything other then scrolling line-by-line from the beginning of the file can screw up the highlighting. This includes using pageup/pagedown a lot, as well as opening the file some screenfuls down from the beginning. I /think/ this can be fixed, because when I first started working on the Pod highlighting this happened a lot, but now I can start anywhere in a Pod file and hit pageup/down at will without screwing up the highlighting.

• Improve performance. Some tradeoffs and/or cleverness need to be employed to make it faster. It might also make sense to make more parts of the highlighting optional.

How does one measure performance? Why do you say performance needs to be improved?

You can see for yourself by opening a relatively long Perl 6 file and trying to scroll. The CPU usage will be higher than when scrolling through e.g. Perl 5 code and it might even be noticably slower (it is on my 1.7GHz Pentium M laptop). This is of course due the sheer amount and complexity of the regular expressions found in the syntax file. It's certainly the longest one I know of. :)

For a crude example of this, try opening t/spec/S02-literals/quoting.t from the pugs repo and doing ":let perl6_extended_q=1" and then ":set ft=perl6". It takes a few seconds just to load on my machine.

So you're going strictly off of user perception right now, it sounds like. Are there any metrics we can work on so that when we work on speeding it up we can quantify it?

I don't know of any, but it would be nice to have some.

We can use this for now:

$ time vim -RXZ -i NONE -u NONE -N -n '+set nomodeline' '+filetype on' '+set filetype=perl6' '+syntax on' '+q' t/spec/S02-literals/quoting.t 

real    0m0.097s
user    0m0.064s
sys 0m0.012s

$ time vim -RXZ -i NONE -u NONE -N -n '+set nomodeline' '+let perl6_extended_q=1' '+set filetype=perl6' '+syntax on' '+q' t/spec/S02-literals/quoting.t 

real    0m12.404s
user    0m7.644s
sys 0m3.956s

That's fantastic, hinrik. Thank you very much.

Hm. I thought it was differentiated enough by having interpolated things appear different depending on the string.

Hrm, I think my original request was poorly worded. The reasoning is an extension of the coding style that one shuold be using interpolating strings only when necessary, and non-interpolated strings in all other cases. This would simply facilitate that behavior.

It's relatively easy to change the color of the quoting characters ( "", '', qx//, etc) depending on if they interpolate. I could add that.

Another (much more difficult) way would be to change the background color to either single or double-quoted strings. That approach has its own problems, though. The highlighting groups for strings (perlString and perlStringUnexpanded) are usually just linked to vim's builtin Constant group, and your colorscheme might change the color of Constant. The problem here is that we can't tell vim to "use the foreground color of the Constant group and the background color of this other group". It's even more difficult considering that the only syntax groups which usually have background colors are Error and Todo, so either of those would have to be picked, which I don't think would be optimal.

My hack basically did this by going through and finding all the region/match that used non-interpolating constructs and turned them into nameSQ or the like. Added that as a separate hilite group at the end of the file. Crude, I don't really know the vim syntax grammar very well but it worked with my limited tests. Only thing that didn't was the fact that the constructs themselves were colored as regular strings and not as the "new" category.

I vote against this idea. It's fine the way it is. The interpolating strings look interpolating when things inside get interpolated. Alternate background colors would be really irritating, particularly for users that do not have the same background colors as you do.

This has been handled correctly for a long time by mauke's perl.vim, which you can also find in my fork of Andy's vim-perl repo.

You are right, your fork does have it correctly. I don't know the relationship between your fork and Andy's so I'm uncertain of the status of this issue then.

hinrik and I need to get our acts together, merging his fork back down to mine.

I forked and added some symbols for qq symbols I use.. I don't really expect my changes to get pulled in, but I do wish there were a for-looping style way to include all the symbols that are valid perl without screwing up other syntax. It'd help if vim's syntax parser was actually a language parser.

I wouldn't presume anything. Anything that is useful could well get in.

I should say, I expect the q[xw] to include valid symbols, but not necessarily the way I did it in my fork then. Somehow my mind rejects 200 lines of those region patterns.

I think this is best discussed on the mailing list.

I think this can be closed, as the relevant changes have been merged in.

Probably the best way to enable this would be an alternative syntax file that was enabled somehow. I'm sure there's a way to enable a syntax based on a given string being present in a file.

Using another syntax file (which inherits from perl.vim) would mean that those using the new keywords would have to add a modeline to their files (e.g. "# vim: filetype=perl_moose").

Another way would be to add a configuration option to perl.vim which enables highlighting of those keywords. That way it could be enabled per-file with a modeline or globally in a user's ~/.vimrc.

The latter thing that hinrik said is more what I was thinking. Because then you could have things like: # vim: perl_extra=try_catch,moose_declare

And you could use different combinations reasonably.

I'd definetly find this nice to have. I wouldn't mind simple having a vimrc setting appropriate for it if it is at all possible. Right now I've hacked up my perl.vim to include the exports of Test::More, Test::Exception, Scalar::MoreUtils, and List::MoreUtils.

what about to use/merge some features from this syntax file: http://www.vim.org/scripts/script.php?script_id=2526

line 10 is correctly highlighted with hinrik's branch. But line 11 is still as it is here.

I just fixed this: http://github.com/hinrik/vim-perl/commit/94c2301469a5a5b9ab318b189cf291a86cf61655

hinrik++

This has been merged, so the issue may be closed.

I recall reading a comment in the perl.vim file that this was something that was particularly difficult to accomplish.

316 " Constructs such as print <<EOF [...] EOF, 'here' documents
317 "
318 " XXX Any statements after the identifier are in perlString colour (i.e.
319 " 'if $a' in 'print <<EOF if $a'). This is almost impossible to get right it
320 " seems due to the 'auto-extending nature' of regions.

This is an option already, you just need to add:

let perl_include_pod = 1

To your .vimrc

What doesn't look quite right? The escaped quotes look alright here. I.e. they look like other escape sequences (\t, \e, etc).

I've got something in my fork now that we can use. See http://blog.nix.is/testing-vim-syntax-files

I'm unable to reproduce this. Can you paste a code sample that triggers this?

Here's a small sample:

package Package;

=head1 HEAD

Lalala pod text
package blarg asdf
lalalamorepod

=head2 HEAD2

Moar pod.

=cut

This is highlighted correctly on my machine. Are you using the perl.vim and pod.vim from this repository?

From :scriptnames:

43: /usr/share/vim/vimfiles/syntax/perl.vim
44: /usr/share/vim/vimfiles/syntax/pod.vim
45: /usr/share/vim/vim72/syntax/pod.vim
46: /usr/share/vim/vim72/syntax/perl.vim
47: /usr/share/vim/vimfiles/indent/perl.vim
48: /usr/share/vim/vim72/indent/perl.vim

The one in vimfiles is the one that's from this repo, the one in vim72 is the one that comes with vim.

Odd. My setup is very much like yours.

I have a current version of my ~/.vimrc here, if that helps you diagnose things any better.

I can reproduce this on several different machines, running different versions of vim, and on both FreeBSD and Linux. They all use roughly this same custom setup, though.

Ah. I have let perl_nofold_packages=1 in my ~/.vimrc and you don't. I just tried removing it, and I get the same issue. At first glance I don't see why perl.vim is causing this, but I'll look into it further in a bit.

I have fixed this. Until Andy merges it in, you can get it from my fork.

Now folding doesn't work properly. I can fold pod chunks, but I can't fold packages or subs.