Note: Beware! Default reply-to is to the list.
Hello, Second take. 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. Anne 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. > > > Hi, > > 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 > > =cut > > ever so much more perl code > .......... > even more ever so much more perl code > .......... > end of ever so much more perl code > 1; > __END__ > > =head1 HEADING > > final pod comments > more final pod comments > > =cut > > 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. > > Thanks > Anne > _______________________________________________ > Za-pm mailing list > Za-pm@pm.org > http://mail.pm.org/mailman/listinfo/za-pm > > posts also archived on Mail Archive > http://www.mail-archive.com/za-pm@pm.org/ _______________________________________________ Za-pm mailing list Za-pm@pm.org http://mail.pm.org/mailman/listinfo/za-pm posts also archived on Mail Archive http://www.mail-archive.com/za-pm@pm.org/