Note: Beware! Default reply-to is to the list.
Actually vim is better behaved than I described, its perl highlighting
puts all the pod elements and comments in one common colour, which
behaviour stays the same irrespective of the location of the __END__
token, it is in gvim that the elements (like head1) are in a
distinctive colour that evaporates if the __END__ token precedes them.
So I think that gedit just has its little ways. The loss of
highlighting made me think I had something wrong, that was really the
issue that threw me.
On Wed, 29 Sep 2010 21:22:44 +0200
Anne Wainwright <anothera...@fables.co.za> wrote:
> Note: Beware! Default reply-to is to the list.
> After studying harder and getting my brain around complex data
> structures I am off charging (well, relatively so) thru the new
> Catalyst book, putting in the examples and getting them to work and
> understanding how they work. Now:
> Please tell me that i have this right
> perl file outline:
> appropriate #! start stuff
> perl code
> even more perl code
> end of perl code
> =head1 HEADING
> pod comments
> more pod comments
> ever so much more perl code
> even more ever so much more perl code
> end of ever so much more perl code
> =head1 HEADING
> final pod comments
> more final pod comments
> The __END__ token signifies to the parser that there is definitely no
> more perl code past that point only, in this case, pod stuff
> The perl syntax highlighting in gedit stops at the __END__ token, that
> is to say that past that point =head1 & =cut do not have the benefit
> of the editor syntax highlighting.
> Does this happen with all other editors? (I know it does in gVim as
> well). I just wondered where the highlighting went to, it usually
> gives in when you have something wrong, not when you have it right
> for once.
> It's sort of logical, and sort of not. Either the editor is going to
> supply highlighting or it isn't. Only if I put the __END__ token at
> the _very_ end of the file, past the final =cut, is the highlighting
> of the pod elements restored, but this sort of negates the purpose of
> the __END__ token (presumably to mark the end of code to be parsed and
> thus save time normally spent parsing non-code pod stuff.
> Does any one take issue with the putting of the __END__ token right
> after the 1; and forget about the highlighting of the final batch of
> pod stuff? Are some other editors better behaved?
> ps. just doing small stuff I stick with gedit, but am investigating
> vim just in case.
> Za-pm mailing list
> posts also archived on Mail Archive
Za-pm mailing list
posts also archived on Mail Archive