Syntax parsing: A lone =cut is not parsed as a POD starter

[SineSwiper]

Due to a quirk with how Perl POD gets parsed, this rule is followed to the strictest level:

A Pod block starts with any command paragraph

This includes a =cut command, when no POD block was started. For example:

sub thing_one {}

=cut

sub thing_two {}

=head1 OTHER THINGS

=cut

sub thing_three {}

The first =cut here is not considered to be a POD ender, but a POD starter, and the thing_two sub is swallowed up into the POD. This is unintuitive, but also something that P5P isn't likely going to be able to fix without breaking backwards-compatibility.

This sort of thing is highlighted correctly in Vim, but the Perl Navigator syntax colorization thinks that the lone =cut is a POD ender, so there's no indication that anything is wrong.

[bscan]

Thanks for filing the issue. This is an interesting edge case. I believe the issue is here:

PerlNavigator/server/perl.tmLanguage.json

Line 14 in f0d3021

"begin": "^(?==[a-zA-Z]+)",

The use of positive lookahead means that the =cut is not consumed by the parser, and is matched immediately as a closing tag as well. However, we can't simply remove the positive lookahead because of special pod formatting like =begin html. The #pod section requires that =begin html is passed to the section for further formatting. Similarly, vscode currently highlights "command paragraphs" like =head1 differently than =arbitraryTitle even though the latter still starts a POD section.

The easiest is probably just adding a special case for pod blocks that begin with =cut. Open to pull requests, or I'll get around to it at some point. I'm a bit behind on project maintenance here, but hopefully will catch up soon.