Ever wonder how much of our programming style is dictated by our desire to see the right pretty colors? In Perl, I think it's a good bit.
For example, I know that the person who wrote this line wasn't using Vim's default Perl syntax:
Account->q(accountid => $self->{accountid});
...because it would interpret q(...) as a non-interpolative string. Meanwhile, the guy who wrote this was:
$logger->("setting account information to \%info");
...because syntax highlighting told him that %info was a variable, even though Perl doesn't interpolate hashes.
I always put spaces around my range operators, because otherwise in 1..2 the dots are different colors.
Other examples welcome.
#!# A very important comment that want everyone to notice
Re:I'm Guilty
sigzero on 2008-10-08T17:49:44
I am color weak so that is hard for me to tell so I just use # XXX to have something stand out.
Re:I'm Guilty
Mr. Muskrat on 2008-10-08T17:59:55
Heh. I also use that trick from time to time. That reminds me, I need to modify my Vim config to make '# BUG' stand out in red.# BUG
Mr. Muskrat on 2008-10-08T18:25:39
I copied the perl syntax file to my.vim directory and tweaked it to highlight bug comments differently. 'BUG' gets colored white on red and the rest of the comment in the normal cyan (if you use the default color scheme). [mmusgrove@test perl]$ diff
/usr/share/vim/vim70/syntax/perl.vim ~/.vim/syntax/perl.vim
125a126
> syn keyword perlBug BUG contained
371c372
< syn match perlComment "#.*" contains=perlTodo
---
> syn match perlComment "#.*" contains=perlTodo,perlBug
525a527
> HiLink perlBug ErrorRe:# BUG
sigzero on 2008-10-09T20:41:37
Hey that can be handy...why not send the diff the the perl.vim maintainer?
Re:# BUG
Mr. Muskrat on 2008-10-10T00:15:51
The patch has been sent to the current maintainer, Nick Hibma.
$root->findnodes(qq[
//ATTRIBUTE[($NAME="$bckwrd_wf" or $NAME="$bckwrd_ses") and $VALUE="NO"]/$VALUE |
//TASKINSTANCE[$FPDNR="NO"]/$FPDNR |
//TASKINSTANCE[$FPIF="NO"]/$FPIF
])
VS. this:
$root->findnodes("
//ATTRIBUTE[($NAME="$bckwrd_wf" or $NAME="$bckwrd_ses") and $VALUE="NO"]/$VALUE |
//TASKINSTANCE[$FPDNR="NO"]/$FPDNR |
//TASKINSTANCE[$FPIF="NO"]/$FPIF
")
The variables look the same in Vim, but in the qq version, the and's and or's and "//" stand out better, and even the element names (e.g., "ATTRIBUTE") stand out better. All in all prettier. Only works with some qq delimiters, square brackets are ok, "-" is ok, but curly braces come out the same as using quotes. Similar behavior with q[]. If it's a bug I hope they don't fix it
Re:YAML and emacs
jrockway on 2008-10-09T01:21:48
Try the real YAML mode instead of the one based on generic.
http://www.emacswiki.org/cgi-bin/wiki/YamlMode
Re:YAML and emacs
srezic on 2008-10-09T20:18:31
I am already using this mode. The update from 0.0.2 to 0.0.3 did not help, unfortunately.
I've thought about this a lot. For a long time, I avoided chained method calls, like:
$foo->bar->baz(123, "abc");
or:
$foo->{bar}->baz(123);
because only the first method was highlighted as such. Some day I discovered perl-mauke.vim [1] which made lots of things better. However, there are still some things I avoid because of Vim. However, that's probably just me. I also avoid modules with names that are not correctly camel-cased (in my understanding), or methods that start with an uppercase letter. And the list goes on...
[1] http://www.vim.org/scripts/script.php?script_id=2300
A huge pain in the ass for me is that literal barewords for fat commas are falsely shown as keywords.
foo( reset => 1 );
Another big one, for me at least, is that all POD blocks should start with =pod, otherwise the relatively simple comment checker in Ultraedit can't handle it.
Re:fat commas
Mr. Muskrat on 2008-10-10T15:35:55
Using a keyword as a bareword is what causes this. I haven't looked into fixing it as I see it as a feature. Tryfoo( bar => 1 );
and you'll see that bar is treated like quoted text.