in reply to Unexpected HTML from POD

I don't have the answer to your question, but I noticed that the "code" HTML tags disappear if you get rid of the empty parentheses in your POD: 
BackupTRM As Boolean

[download]
Searching through the docs, here is the closest thing I see, from perlpodspec (emphasis mine):
At time of writing, L<name> values are of two types: either the name of a Pod page like L<Foo::Bar> (which might be a real Perl module or program in an @INC / PATH directory, or a .pod file in those places); or the name of a Unix man page, like L<crontab(5)> . In theory, L<chmod> in ambiguous between a Pod page called "chmod", or the Unix man page "chmod" (in whatever man-section). However, the presence of a string in parens, as in "crontab(5)", is sufficient to signal that what is being discussed is not a Pod page, and so is presumably a Unix man page. The distinction is of no importance to many Pod processors, but some processors that render to hypertext formats may need to distinguish them in order to know how to render a given L<foo> code.
Looking through the source code of Pod::Html, I see this comment: 
    # has parenthesis so should have been a C<> ref
    ## try for a pagename (perlXXX(1))?

[download]

Replies are listed 'Best First'.
Re^2: Unexpected HTML from POD
by davies (Monsignor) on Jan 11, 2011 at 16:07 UTC

    Thanks. It seems the behaviour is intended but undocumented! Just above the comments in the source code that you quoted is a regex test that is looking for certain specific things in brackets. One of the things it looks for - six lines above your comment - is nothing. So in the POD I am giving it, it sees a function name followed by nothing in brackets and that matches this regex. Therefore, like Bill Gates, it knows best. I can't see any options that refer to this and it seems that the only way to change the behaviour is to change the code. The smallest amount of work, since I want this to work on any machine, is to change my code. I have code that writes POD, and changing this to include s/()/(Z<>)/g is not too challenging. I think all I have to do is work out which of those characters need escaping.

    Regards,

    John Davies

[reply]
[d/l]
      > Thanks. It seems the behaviour is intended but undocumented!

      Hmm, will you send a bug report?

      Cheers Rolf

[reply]

        I hadn't planned to, since the behaviour was clearly intended. If you think it would help, I shall gladly do so if I can work out the intricacies and identity of the bug reporting system.

        Regards,

        John Davies
[reply]

In Section Seekers of Perl Wisdom