in reply to Re: Some thoughts around the "is Perl code maintainable" discussion
in thread Some thoughts around the "is Perl code maintainable" discussion

syntax highlighting is fantastic, and yet i've never seen an editor get it right for perl.

i've got a number of source files littered with #'#fix vim highlight to give hints to the editor that, no, s|'|"|g; is not the start of a runaway string.

only perl can parse Perl is the usual mantra. most software can't do it -- no wonder humans have trouble, too. ;-)

Replies are listed 'Best First'.
Re^3: Some thoughts around the "is Perl code maintainable" discussion
by grep (Monsignor) on Aug 12, 2007 at 00:43 UTC
    yet i've never seen an editor get it right for perl

    I've been more than happy with emacs's cperl-mode (and mostly happy with perl-mode) syntax highlighting. So IMO emacs gets it right.

    grep

[reply]
      Open up the source of SOAP::Transport::HTTP... does it look OK to you? (Scroll through the whole file)

      Seems really screwed here.

      YMMV.

      -David

[reply]
        I assume you didn't expect me to actually look... but I did.

        I used SOAP version 0.28, emacs 21.4.1 with it's current version of cperl-mode.
        I looked at

        • SOAP::Transport::HTTP::Apache
        • SOAP::Transport::HTTP::CGI
        • SOAP::Transport::HTTP::Client
        • SOAP::Transport::HTTP::Server
        I saw no mistakes in syntax highlighting. So unless you have a specific complaint, I would suggest checking out your assertion before you post. I'll be quite happy to post screen shots if needed.

        grep

[reply]
Re^3: Some thoughts around the "is Perl code maintainable" discussion
by blazar (Canon) on Aug 12, 2007 at 16:33 UTC
    syntax highlighting is fantastic, and yet i've never seen an editor get it right for perl.

    Yep, but then I bet that even perl, which can properly parse Perl, would have some difficulties syntax-highlighting certain kinds of code in a meaningful manner. OTOH most smart enough editors do a decent job on most reasonable and common code. Sometimes you have to trick them or help them in some way. Mine not only helps me with SH, but also does automatic indentation etc. but again in some cases it gets it wrong, e.g. with

    local ($,,$\)=("\n") x 2;

    [download]
    In this case the closing parenthesis is seen as quoted, and this screws up the following lines of code. Of course using 
    local ($\,$,)=("\n") x 2;

    [download]

    instead prevents the problem, and is also clearer a priori, but it was just to come out with a reasonably "real" enough example.

    Similar situations when here docs are included, even more so if they actually contain code. Then, in the rare situations in which I need to do a string eval, I prefer

    q{ ... };  # or
qq{ ... };

    [download]

    Over simple quotes, since then my editor won't recognize them as strings, but mistake them for code blocks, which is fine in this case. The Right Thing™ would have been... ehm "wrong" in this case.

    In some regexen like the one you mentioned, I overquote inside the regex, just not incur your same problem.

    Oh, and as a minor point, comments are only recognized if there's some whitespace on the left of #. So I always include some, but that's not a big harm since I consider it a good practice anyway. OTOH when I have to comment out big portions of code I use the "indent region" function of the editor itself, which is a big help especially in connection with its "unindent region" companion.

    One thing that is occasionally annoying is the confusion between "multi line" anonymous hashrefs and code blocks: to cope with that I often put parentheses instead, that I substitute with curlies later. Not terribly hard, but... well, annoying.

[reply]
[d/l]
[select]
      > One thing that is occasionally annoying is the
      > confusion between "multi line" anonymous hashrefs and
      > code blocks: to cope with that I often put parentheses
      > instead, that I substitute with curlies later. Not
      > terribly hard, but... well, annoying.

      In my extensions to cperl-mode for Perl6 syntax (and here) I made a Perl6 like distinction between hashes and blocks in a way that no whitespace is allowed before the curlies of hashes. With that the distinction of hashes and blocks generally works better.

      I always use my enhanced variant of cperl-mode also for Perl5 code due to features like this, so maybe you also give it a try.

[reply]
        I always use my enhanced variant of cperl-mode also for Perl5 code due to features like this, so maybe you also give it a try.

        Thank you very much, and good to let people know, for all the others experiencing a similar problem. But you wrongly assumed I use something a .el thingie could run on: however do not fear, I'm not in "the" other camp. Amongst the two contendants I chose a third beast... :-)

[reply]

In Section Meditations