Ricardo SIGNES wrote:
perlpodspec gives "two syntaxes" for formatting codes. There's X<content> and
X<< content >>. In the "two or more angle brackets" form, the whitespace
immediately following << and preceding >> are not renderable. That's fine, but
I'm confused as to why that isn't just the universal case. Is it just a
backcompat issue that someone might have been relying on B< foo > having spaces
at either end?
It would be a simple enough change, may catch a few people out, but
won't do any serious harm. On the other hand, it could be argued that
it's hardly worth changing the spec for Perl 5 Pod at this point,
especially a change that minor.
I've been pondering how to simplify how some things are explained, and that's
one place where I think the spec itself could be simplified without any real
problems.
To simplify the explanation without changing the implementation, just
tell people not to include any spaces right inside the formatting codes
(most people don't put spaces there anyway).
Also, because it seems almost absurd for the opposite to be true, I'm currently
assuming that a formatting code may *never* have a blank line in its contents.
That is, this is illegal:
I love you B<
very
> much.
I realize these are edge cases. I'm only asking because I'm interested in
opinions, not because I think it will come up frequently.
As in, it's okay to span multiple lines, but all lines have to be
adjacent? Yes, that's already in the spec. The blank line defines the
boundary of a paragraph, so all it's really saying is that formatting
codes can't span paragraph boundaries.
---------
perlpodspec.pod
Formatting codes absolutely cannot span paragraphs. If a code is opened
in one paragraph, and no closing code is found by the end of that
paragraph, the Pod parser must close that formatting code, and should
complain (as in "Unterminated I code in the paragraph starting at line
123: 'Time objects are not...'").
----------
Allison
