=for comment
Hm, I wonder what it would look like if
you tried to write a BNF for Pod from this.
-
+
=head3 Dr. Strangelove, or: How I Learned to
Stop Worrying and Love the Bomb
# <- that's the 0th column
=head1 Foo
-
+
Stuff
-
+
$foo->bar
-
+
=cut
Here, "=head1 Foo" and "=cut" are command paragraphs because the first
is a heading. That text may contain formatting codes. Examples:
=head1 Object Attributes
-
+
=head3 What B<Not> to Do!
=item "=pod"
it must be ignored. Examples:
=pod
-
+
This is a plain Pod paragraph.
-
+
=pod This text is ignored.
=item "=cut"
below. Formatting codes are not expanded. Examples:
=over 3
-
+
=over 3.5
-
+
=over
=item "=item"
below. Examples:
=item
-
+
=item *
-
+
=item *
-
+
=item 14
-
+
=item 3.
-
+
=item C<< $thing->stuff(I<dodad>) >>
-
+
=item For transporting us beyond seas to be tried for pretended
offenses
-
+
=item He is at this time transporting large armies of foreign
mercenaries to complete the works of death, desolation and
tyranny, already begun with circumstances of cruelty and perfidy
This is synonymous with:
=begin formatname
-
+
text...
-
+
=end formatname
That is, it creates a region consisting of a single paragraph; that
two paragraphs:
I<I told you not to do this!
-
+
Don't make me say it again!>
...must I<not> be parsed as two paragraphs in italics (with the I
above code must parse as if it were:
I<I told you not to do this!>
-
+
Don't make me say it again!E<gt>
(In SGMLish jargon, all Pod commands are like block-level
Minimal examples:
%% POD::Pod2PS v3.14159, using POD::Parser v1.92
-
+
<!-- Pod::HTML v3.14159, using POD::Parser v1.92 -->
-
+
{\doccomm generated by Pod::Tree::RTF 3.14159 using Pod::Tree 1.08}
-
+
.\" Pod::Man version 3.14159, using POD::Parser version 1.92
Formatters may also insert additional comments, including: the
Pod parsers, when processing a series of verbatim paragraphs one
after another, should consider them to be one large verbatim
paragraph that happens to contain blank lines. I.e., these two
-lines, which have an blank line between them:
+lines, which have a blank line between them:
use Foo;
which all Pod formatters must render faithfully. Characters
in the ranges 0-31 and 127-159 should not be used (neither as
literals, nor as EE<lt>number> codes), except for the
-literal byte-sequences for newline (13, 13 10, or 13), and tab (9).
+literal byte-sequences for newline (13, 13 10, or 10), and tab (9).
Characters in the range 160-255 refer to Latin-1 characters (also
defined there by Unicode, with the same meaning). Characters above
presumably does not I<need> special treatment by a Pod processor;
" 0 1 2 3 " doesn't look like a number in any base, so it would
presumably be looked up in the table of HTML-like names. Since
-there is (and cannot be) an HTML-like entity called " 0 1 2 3 ",
+there isn't (and cannot be) an HTML-like entity called " 0 1 2 3 ",
this will be treated as an error. However, Pod processors may
treat "EE<lt> 0 1 2 3 >" or "EE<lt>e-acute>" as I<syntactically>
invalid, potentially earning a different error message than the
anything, renderable or not). It is good practice to map Latin letters
with diacritics (like "EE<lt>eacute>"/"EE<lt>233>") to the corresponding
unaccented US-ASCII letters (like a simple character 101, "e"), but
-clearly this is often not feasable, and an unrenderable character may
+clearly this is often not feasible, and an unrenderable character may
be represented as "?", or the like. In attempting a sane fallback
(as from EE<lt>233> to "e"), Pod formatters may use the
%Latin1Code_to_fallback table in L<Pod::Escapes|Pod::Escapes>, or
=item *
-Some processors may find it the C<SE<lt>...E<gt>> code easiest to
+Some processors may find that the C<SE<lt>...E<gt>> code is easiest to
implement by replacing each space in the parse tree under the content
of the S, with an NBSP. But note: the replacement should apply I<not> to
spaces in I<all> text, but I<only> to spaces in I<printable> text. (This
Besides the NBSP character discussed above, implementors are reminded
of the existence of the other "special" character in Latin-1, the
-"soft hyphen" chararacter, also known as "discretionary hyphen",
+"soft hyphen" character, also known as "discretionary hyphen",
i.e. C<EE<lt>173E<gt>> = C<EE<lt>0xADE<gt>> =
C<EE<lt>shyE<gt>>). This character expresses an optional hyphenation
point. That is, it normally renders as nothing, but may render as a
in L<Getopt::Std/DESCRIPTION>, "DESCRIPTION" is the section. (Note
that this is not the same as a manpage section like the "5" in "man 5
crontab". "Section Foo" in the Pod sense means the part of the text
-that's introduced by the heading or item whose text is "Foo".
+that's introduced by the heading or item whose text is "Foo".)
=back
<h1><a name="About_the_-M_Operator">About the <code>-M</code>
Operator</h1>
-
+
...
-
+
<a href="somedoc#About_the_-M_Operator">About the <code>-M</code>
Operator" in somedoc</a>
with no accompanying paragraph. The middle item is an example:
=over
-
+
=item 1
-
+
Pick up dry cleaning.
-
+
=item 2
-
+
=item 3
-
+
Stop by the store. Get Abba Zabas, Stoli, and cheap lawn chairs.
-
+
=back
=item *
content. That is, authors should not have an empty region like this:
=over
-
+
=back
Pod processors seeing such a contentless "=over" ... "=back" region,
=item Porro
=item Quisquam Est
-
+
Qui dolorem ipsum quia dolor sit amet, consectetur, adipisci
velit, sed quia non numquam eius modi tempora incidunt ut
labore et dolore magnam aliquam quaerat voluptatem.
"Ut Enim". In that case, you'd want to format it like so:
Neque
-
+
Porro
-
+
Quisquam Est
Qui dolorem ipsum quia dolor sit amet, consectetur, adipisci
velit, sed quia non numquam eius modi tempora incidunt ut
Ut Enim
-That is, there should be (at least roughtly) equal spacing between
+That is, there should be (at least roughly) equal spacing between
items as between paragraphs (although that spacing may well be less
than the full height of a line of text). This leaves it to the reader
to use (con)textual cues to figure out whether the "Qui dolorem
a specific format:
=begin rtf
-
+
\par{\pard\qr\sa4500{\i Printed\~\chdate\~\chtime}\par}
-
+
=end rtf
The exact same effect could, incidentally, be achieved with a single
Another example of a data paragraph:
=begin html
-
+
I like <em>PIE</em>!
-
+
<hr>Especially pecan pie!
-
+
=end html
If these were ordinary paragraphs, the Pod parser would try to
I<identifier> begins with a colon, I<can> contain commands. For example:
=begin :biblio
-
+
Wirth's classic is available in several editions, including:
-
+
=for comment
hm, check abebooks.com for how much used copies cost.
-
+
=over
-
+
=item
-
+
Wirth, Niklaus. 1975. I<Algorithmen und Datenstrukturen.>
Teubner, Stuttgart. [Yes, it's in German.]
-
+
=item
-
+
Wirth, Niklaus. 1976. I<Algorithms + Data Structures =
Programs.> Prentice-Hall, Englewood Cliffs, NJ.
-
+
=back
-
+
=end :biblio
Note, however, a "=begin I<identifier>"..."=end I<identifier>"
nor "=item". For example, this may be considered invalid:
=begin somedata
-
+
This is a data paragraph.
-
+
=head1 Don't do this!
-
+
This is a data paragraph too.
-
+
=end somedata
A Pod processor may signal that the above (specifically the "=head1"
I<not> be treated as an error:
=begin somedata
-
+
This is a data paragraph.
-
+
=cut
-
+
# Yup, this isn't Pod anymore.
sub excl { (rand() > .5) ? "hoo!" : "hah!" }
-
+
=pod
-
+
This is a data paragraph too.
-
+
=end somedata
And this too is valid:
=begin someformat
-
+
This is a data paragraph.
-
+
And this is a data paragraph.
-
+
=begin someotherformat
-
+
This is a data paragraph too.
-
+
And this is a data paragraph too.
-
+
=begin :yetanotherformat
=head2 This is a command paragraph!
This is an ordinary paragraph!
-
+
And this is a verbatim paragraph!
-
+
=end :yetanotherformat
-
+
=end someotherformat
-
+
Another data paragraph!
-
+
=end someformat
The contents of the above "=begin :yetanotherformat" ...
Also consider this valid structure:
=begin :biblio
-
+
Wirth's classic is available in several editions, including:
-
+
=over
-
+
=item
-
+
Wirth, Niklaus. 1975. I<Algorithmen und Datenstrukturen.>
Teubner, Stuttgart. [Yes, it's in German.]
-
+
=item
-
+
Wirth, Niklaus. 1976. I<Algorithms + Data Structures =
Programs.> Prentice-Hall, Englewood Cliffs, NJ.
=back
-
+
Buy buy buy!
-
+
=begin html
-
+
<img src='wirth_spokesmodeling_book.png'>
-
+
<hr>
-
+
=end html
-
+
Now now now!
-
+
=end :biblio
There, the "=begin html"..."=end html" region is nested inside
paragraphs. I.e., these should be tolerated:
=for html
-
+
=begin html
-
+
=end html
-
+
=begin :biblio
-
+
=end :biblio
Incidentally, note that there's no easy way to express a data
paragraph starting with something that looks like a command. Consider:
=begin stuff
-
+
=shazbot
-
+
=end stuff
There, "=shazbot" will be parsed as a Pod command "shazbot", not as a data
is, they must properly nest. For example, this is valid:
=begin outer
-
+
X
-
+
=begin inner
-
+
Y
-
+
=end inner
-
+
Z
-
+
=end outer
while this is invalid:
=begin outer
-
+
X
-
+
=begin inner
-
+
Y
-
+
=end outer
-
+
Z
-
+
=end inner
-
+
This latter is improper because when the "=end outer" command is seen, the
currently open region has the formatname "inner", not "outer". (It just
happens that "outer" is the format name of a higher-up region.) This is
an error. Processors must by default report this as an error, and may halt
-processing the document containing that error. A corrolary of this is that
+processing the document containing that error. A corollary of this is that
regions cannot "overlap" -- i.e., the latter block above does not represent
a region called "outer" which contains X and Y, overlapping a region called
"inner" which contains Y and Z. But because it is invalid (as all
Similarly, this is invalid:
=begin thing
-
+
=end hting
This is an error because the region is opened by "thing", and the "=end"
This is also invalid:
=begin thing
-
+
=end
This is invalid because every "=end" command must have a formatname
https://perl5.git.perl.org / perl5.git / blobdiff