POD6 consistency problems

[finanalyst]

1. Rakudo does not properly implement Pod::Block::Table or Pod::Defn because these blocks do not contain Pod::Blocks relating to embedded POD6. Other Pod::Blocks allow for Pod::Blocks to be recursively embedded.
2. Extend POD6 specification so that all Pod::FormattingCode objects follow the behaviour of L<>, X<>, and P<>.

---

There is a difference between POD6 implementation problems, covered here, and the way POD6 is rendered, which is mostly the content of #69. The renderer Pod::To::HTML2 (in raku-pod-render) handles some of the problems in #69, eg. P<>. P<> is correctly implemented by Rakudo, but is not rendered by Pod::To::HTML. Moreover, Pod::To::HTML does not provide a mechanism for Custom Pod or FormattingCode blocks, which is specified, but Pod::To::HTML2 does provide a mechanism to render custom blocks.

Implementation error: Allow for Pod to be embedded in Pod::Block::Table and Pod::Defn (also possibly Pod::Headings)

• This bug is reported as an issue for Pod::To::HTML, but it is not a rendering issue because the Pod::Block::Table returned by the compiler does not recursively contain Pod::Blocks which could be properly rendered.
• This is an implementation flaw because there is nothing in the Specifications to indicate embedding should not be done.
• There is a test in the Pod::To::HTML test suite for embedded tables, but it is fudged.
• I think the flaw arose because the current syntax for POD6 tables was changed from Damian's original specification

Language Extension: Extend the syntax of FormattingCodes L<>, X<> and P<> to all FormattingCodes. FormattingCode P, X & L have the form, eg for X, X< some text that will be in the Contents | a list that will be in Meta >

• When P, L or X are processed by Rakudo, a Pod::FormattingCode object is returned in which the contents attribute is set to 'some text that will be in the Contents', and the meta attribute is set to the scalar or list after the |.
• The Renderer then handles the contents and meta parts appropriately (or not).
• The implemented behaviour fulfills the specification for P, L, X.
• The extension suggested here would enable custom FormattingCodes to be more flexible.
• This extension is implemented by the Pod::To::HTML2 renderer by parsing the contents string of a non-standard Pod::Formatting block.

---