Every repository with this icon (
) is private.
Every repository with this icon (
) is public.
| Description: | Support for Perl 5 and Perl 6 in Vim edit |
-
2 votes
Differentiate between interpolated and non-interpolated strings
5 comments Created 5 months ago by dekimseyIs 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.
Comments
-
1 vote
qw highlighting misses some forms of legal punctuation
8 comments Created 5 months ago by dekimseyIt 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".
Comments
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.
-
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.
Comments
kentfredric
Wed Jun 03 07:41:53 -0700 2009
| link
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
-
// # colourised as a quote operator
//= # colourised as a quote operator followed by = ( which is coloured as a token )
Comments
kentfredric
Wed Jun 03 08:00:44 -0700 2009
| link
line 10 is correctly highlighted with hinrik's branch. But line 11 is still as it is here.
kentfredric
Wed Jun 03 09:00:49 -0700 2009
| link
hinrik++
-
2 votes
Evally sub-regexes should be highlighted as normal perl code.
0 comments Created 5 months ago by kentfredric
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:
Comments
-
If I have something like this:
my $sth = $dbh->prepare(<<'END_SQL', undef, $foo, $bar); select something from somewhere where something_else = 1 END_SQLThen 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.
Comments
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. -
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.
Comments
-
2 votes
Range of 1..3 gets colorized like "1." is part of a decimal number
0 comments Created 5 months ago by petdance1..3 comes out colored wrong. The .. should be seen as an operator.
Comments
-
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?";
Comments
-
Turn on POD formatting if the user has syntax/pod.vim installed.
Comments
-
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) { }
Comments
-
0 votes
Don't highlight ending heredoc markers in POD blocks
0 comments Created 3 months ago by petdanceI have the following chunk of code:
=for when we get switching of instances working my $sql = <<'HERE'; select .... HERE my $row = sqldo_hashref( $sql ... ); =cutand the closing HERE is highlighted. It shouldn't be, because it's all comment in the POD.
Comments
-
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.
Comments
I've got something in my fork now that we can use. See http://blog.nix.is/testing-vim-syntax-files
-
0 votes
'package' on the beginning of a line overrides pod formatting
9 comments Created 2 months ago by piotoRight 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 = 1Comments
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. =cutThis 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.vimThe one in vimfiles is the one that's from this repo, the one in vim72 is the one that comes with vim.
I have a current version of my
~/.vimrchere, 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=1in my~/.vimrcand 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.
-
0 votes
Perl 5: Escaped closing delimiters in SQ strings look wrong
0 comments Created 2 months ago by hinrik'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.Comments
-
0 votes
Arrow operator rendered differently in static vs. object methods
0 comments Created 2 months ago by dekimseyI 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->barcase, but not in theFoo->barcase.
Comments
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.