X-Git-Url: https://perl5.git.perl.org/perl5.git/blobdiff_plain/55a864fe4cea1a0586891b83d359ba71e0972da5..7916a4550fd18ad512e0420ffac716ce1ab89ee7:/pod/perlpod.pod

diff --git a/pod/perlpod.pod b/pod/perlpod.pod
index 6a13991..90bc5b1 100644
--- a/pod/perlpod.pod
+++ b/pod/perlpod.pod
@@ -1,241 +1,737 @@
+
+=for comment
+This document is in Pod format.  To read this, use a Pod formatter,
+like "perldoc perlpod".
+
 =head1 NAME
+X<POD> X<plain old documentation>
 
-perlpod - plain old documentation
+perlpod - the Plain Old Documentation format
 
 =head1 DESCRIPTION
 
-A pod-to-whatever translator reads a pod file paragraph by paragraph,
-and translates it to the appropriate output format.  There are
-three kinds of paragraphs:
+Pod is a simple-to-use markup language used for writing documentation
+for Perl, Perl programs, and Perl modules.
 
-=over 4
+Translators are available for converting Pod to various formats
+like plain text, HTML, man pages, and more.
 
-=item *
+Pod markup consists of three basic kinds of paragraphs:
+L<ordinary|/"Ordinary Paragraph">,
+L<verbatim|/"Verbatim Paragraph">, and 
+L<command|/"Command Paragraph">.
 
-A verbatim paragraph, distinguished by being indented (that is,
-it starts with space or tab).  It should be reproduced exactly,
-with tabs assumed to be on 8-column boundaries.  There are no
-special formatting escapes, so you can't italicize or anything
-like that.  A \ means \, and nothing else.
 
-=item *
+=head2 Ordinary Paragraph
+X<POD, ordinary paragraph>
+
+Most paragraphs in your documentation will be ordinary blocks
+of text, like this one.  You can simply type in your text without
+any markup whatsoever, and with just a blank line before and
+after.  When it gets formatted, it will undergo minimal formatting, 
+like being rewrapped, probably put into a proportionally spaced
+font, and maybe even justified.
+
+You can use formatting codes in ordinary paragraphs, for B<bold>,
+I<italic>, C<code-style>, L<hyperlinks|perlfaq>, and more.  Such
+codes are explained in the "L<Formatting Codes|/"Formatting Codes">"
+section, below.
+
+
+=head2 Verbatim Paragraph
+X<POD, verbatim paragraph> X<verbatim>
+
+Verbatim paragraphs are usually used for presenting a codeblock or
+other text which does not require any special parsing or formatting,
+and which shouldn't be wrapped.
+
+A verbatim paragraph is distinguished by having its first character
+be a space or a tab.  (And commonly, all its lines begin with spaces
+and/or tabs.)  It should be reproduced exactly, with tabs assumed to
+be on 8-column boundaries.  There are no special formatting codes,
+so you can't italicize or anything like that.  A \ means \, and
+nothing else.
+
+
+=head2 Command Paragraph
+X<POD, command>
+
+A command paragraph is used for special treatment of whole chunks
+of text, usually as headings or parts of lists.
 
-A command.  All command paragraphs start with "=", followed by an
-identifier, followed by arbitrary text that the command can
-use however it pleases.  Currently recognized commands are
+All command paragraphs (which are typically only one line long) start
+with "=", followed by an identifier, followed by arbitrary text that
+the command can use however it pleases.  Currently recognized commands
+are
 
-    =head1 heading
-    =head2 heading
-    =item text
-    =over N
+    =pod
+    =head1 Heading Text
+    =head2 Heading Text
+    =head3 Heading Text
+    =head4 Heading Text
+    =over indentlevel
+    =item stuff
     =back
+    =begin format
+    =end format
+    =for format text...
+    =encoding type
     =cut
-    =pod
-    =for X
-    =begin X
-    =end X
-
-The "=pod" directive does nothing beyond telling the compiler to lay
-off parsing code through the next "=cut".  It's useful for adding
-another paragraph to the doc if you're mixing up code and pod a lot.
-
-Head1 and head2 produce first and second level headings, with the text in
-the same paragraph as the "=headn" directive forming the heading description.
-
-Item, over, and back require a little more explanation: "=over" starts a
-section specifically for the generation of a list using "=item" commands. At
-the end of your list, use "=back" to end it. You will probably want to give
-"4" as the number to "=over", as some formatters will use this for indentation.
-This should probably be a default. Note also that there are some basic rules
-to using =item: don't use them outside of an =over/=back block, use at least
-one inside an =over/=back block, you don't _have_ to include the =back if
-the list just runs off the document, and perhaps most importantly, keep the
-items consistent: either use "=item *" for all of them, to produce bullets,
-or use "=item 1.", "=item 2.", etc., to produce numbered lists, or use
-"=item foo", "=item bar", etc., i.e., things that looks nothing like bullets
-or numbers. If you start with bullets or numbers, stick with them, as many
-formatters use the first "=item" type to decide how to format the list.  
-
-For, begin, and end let you include sections that are not interpreted
-as pod text, but passed directly to particular formatters. A formatter
-that can utilize that format will use the section, otherwise it will be
-completely ignored.  The directive "=for" specifies that the entire next
-paragraph is in the format indicated by the first word after
-"=for", like this:
-
- =for html <br> 
+
+To explain them each in detail:
+
+=over
+
+=item C<=head1 I<Heading Text>>
+X<=head1> X<=head2> X<=head3> X<=head4>
+X<head1> X<head2> X<head3> X<head4>
+
+=item C<=head2 I<Heading Text>>
+
+=item C<=head3 I<Heading Text>>
+
+=item C<=head4 I<Heading Text>>
+
+Head1 through head4 produce headings, head1 being the highest
+level.  The text in the rest of this paragraph is the content of the
+heading.  For example:
+
+  =head2 Object Attributes
+
+The text "Object Attributes" comprises the heading there.  (Note that
+head3 and head4 are recent additions, not supported in older Pod
+translators.)  The text in these heading commands can use
+formatting codes, as seen here:
+
+  =head2 Possible Values for C<$/>
+
+Such commands are explained in the
+"L<Formatting Codes|/"Formatting Codes">" section, below.
+
+=item C<=over I<indentlevel>>
+X<=over> X<=item> X<=back> X<over> X<item> X<back>
+
+=item C<=item I<stuff...>>
+
+=item C<=back>
+
+Item, over, and back require a little more explanation:  "=over" starts
+a region specifically for the generation of a list using "=item"
+commands, or for indenting (groups of) normal paragraphs.  At the end
+of your list, use "=back" to end it.  The I<indentlevel> option to
+"=over" indicates how far over to indent, generally in ems (where
+one em is the width of an "M" in the document's base font) or roughly
+comparable units; if there is no I<indentlevel> option, it defaults
+to four.  (And some formatters may just ignore whatever I<indentlevel>
+you provide.)  In the I<stuff> in C<=item I<stuff...>>, you may
+use formatting codes, as seen here:
+
+  =item Using C<$|> to Control Buffering
+
+Such commands are explained in the
+"L<Formatting Codes|/"Formatting Codes">" section, below.
+
+Note also that there are some basic rules to using "=over" ...
+"=back" regions:
+
+=over
+
+=item *
+
+Don't use "=item"s outside of an "=over" ... "=back" region.
+
+=item *
+
+The first thing after the "=over" command should be an "=item", unless
+there aren't going to be any items at all in this "=over" ... "=back"
+region.
+
+=item *
+
+Don't put "=headI<n>" commands inside an "=over" ... "=back" region.
+
+=item *
+
+And perhaps most importantly, keep the items consistent: either use
+"=item *" for all of them, to produce bullets; or use "=item 1.",
+"=item 2.", etc., to produce numbered lists; or use "=item foo",
+"=item bar", etc.--namely, things that look nothing like bullets or
+numbers.
+
+If you start with bullets or numbers, stick with them, as
+formatters use the first "=item" type to decide how to format the
+list.
+
+=back
+
+=item C<=cut>
+X<=cut> X<cut>
+
+To end a Pod block, use a blank line,
+then a line beginning with "=cut", and a blank
+line after it.  This lets Perl (and the Pod formatter) know that
+this is where Perl code is resuming.  (The blank line before the "=cut"
+is not technically necessary, but many older Pod processors require it.)
+
+=item C<=pod>
+X<=pod> X<pod>
+
+The "=pod" command by itself doesn't do much of anything, but it
+signals to Perl (and Pod formatters) that a Pod block starts here.  A
+Pod block starts with I<any> command paragraph, so a "=pod" command is
+usually used just when you want to start a Pod block with an ordinary
+paragraph or a verbatim paragraph.  For example:
+
+  =item stuff()
+
+  This function does stuff.
+
+  =cut
+
+  sub stuff {
+    ...
+  }
+
+  =pod
+
+  Remember to check its return value, as in:
+
+    stuff() || die "Couldn't do stuff!";
+
+  =cut
+
+=item C<=begin I<formatname>>
+X<=begin> X<=end> X<=for> X<begin> X<end> X<for>
+
+=item C<=end I<formatname>>
+
+=item C<=for I<formatname> I<text...>>
+
+For, begin, and end will let you have regions of text/code/data that
+are not generally interpreted as normal Pod text, but are passed
+directly to particular formatters, or are otherwise special.  A
+formatter that can use that format will use the region, otherwise it
+will be completely ignored.
+
+A command "=begin I<formatname>", some paragraphs, and a
+command "=end I<formatname>", mean that the text/data in between
+is meant for formatters that understand the special format
+called I<formatname>.  For example,
+
+  =begin html
+
+  <hr> <img src="thang.png">
   <p> This is a raw HTML paragraph </p>
 
-The paired commands "=begin" and "=end" work very similarly to "=for", but
-instead of only accepting a single paragraph, all text from "=begin" to a
-paragraph with a matching "=end" are treated as a particular format. 
+  =end html
+
+The command "=for I<formatname> I<text...>"
+specifies that the remainder of just this paragraph (starting
+right after I<formatname>) is in that special format.  
+
+  =for html <hr> <img src="thang.png">
+  <p> This is a raw HTML paragraph </p>
+
+This means the same thing as the above "=begin html" ... "=end html"
+region.
+
+That is, with "=for", you can have only one paragraph's worth
+of text (i.e., the text in "=foo targetname text..."), but with
+"=begin targetname" ... "=end targetname", you can have any amount
+of stuff inbetween.  (Note that there still must be a blank line
+after the "=begin" command and a blank line before the "=end"
+command.
 
 Here are some examples of how to use these:
 
- =begin html
+  =begin html
+
+  <br>Figure 1.<br><IMG SRC="figure1.png"><br>
+
+  =end html
+
+  =begin text
+
+    ---------------
+    |  foo        |
+    |        bar  |
+    ---------------
 
- <br>Figure 1.<IMG SRC="figure1.png"><br>
+  ^^^^ Figure 1. ^^^^
 
- =end html
+  =end text
 
- =begin text
+Some format names that formatters currently are known to accept
+include "roff", "man", "latex", "tex", "text", and "html".  (Some
+formatters will treat some of these as synonyms.)
 
-   ---------------
-   |  foo        |
-   |        bar  |
-   ---------------
+A format name of "comment" is common for just making notes (presumably
+to yourself) that won't appear in any formatted version of the Pod
+document:
 
- ^^^^ Figure 1. ^^^^
+  =for comment
+  Make sure that all the available options are documented!
 
- =end text
+Some I<formatnames> will require a leading colon (as in
+C<"=for :formatname">, or
+C<"=begin :formatname" ... "=end :formatname">),
+to signal that the text is not raw data, but instead I<is> Pod text
+(i.e., possibly containing formatting codes) that's just not for
+normal formatting (e.g., may not be a normal-use paragraph, but might
+be for formatting as a footnote).
 
-Some format names that formatters currently are known to accept include
-"roff", "man", "latex", "tex", "text", and "html". (Some formatters will
-treat some of these as synonyms.)
+=item C<=encoding I<encodingname>>
+X<=encoding> X<encoding>
 
-And don't forget, when using any command, that the command lasts up until
-the end of the B<paragraph>, not the line. Hence in the examples below, you
-can see the empty lines after each command to end its paragraph.
+This command is used for declaring the encoding of a document.  Most
+users won't need this; but if your encoding isn't US-ASCII or Latin-1,
+then put a C<=encoding I<encodingname>> command early in the document so
+that pod formatters will know how to decode the document.  For
+I<encodingname>, use a name recognized by the L<Encode::Supported>
+module.  Examples:
+
+  =encoding utf8
+
+  =encoding koi8-r
+  
+  =encoding ShiftJIS
+  
+  =encoding big5
+
+=back
+
+C<=encoding> affects the whole document, and must occur only once.
+
+And don't forget, when using any other command, that the command lasts up
+until the end of its I<paragraph>, not its line.  So in the
+examples below, you can see that every command needs the blank
+line after it, to end its paragraph.
 
 Some examples of lists include:
 
- =over 4
+  =over
+
+  =item *
+
+  First item
+
+  =item *
+
+  Second item
+
+  =back
+
+  =over
+
+  =item Foo()
 
- =item *
+  Description of Foo function
 
- First item
+  =item Bar()
 
- =item *
+  Description of Bar function
 
- Second item
+  =back
 
- =back
 
- =over 4
+=head2 Formatting Codes
+X<POD, formatting code> X<formatting code>
+X<POD, interior sequence> X<interior sequence>
 
- =item Foo()
+In ordinary paragraphs and in some command paragraphs, various
+formatting codes (a.k.a. "interior sequences") can be used:
 
- Description of Foo function
+=for comment
+ "interior sequences" is such an opaque term.
+ Prefer "formatting codes" instead.
 
- =item Bar()
+=over
 
- Description of Bar function
+=item C<IE<lt>textE<gt>> -- italic text
+X<I> X<< IZ<><> >> X<POD, formatting code, italic> X<italic>
 
- =back
+Used for emphasis ("C<be IE<lt>careful!E<gt>>") and parameters
+("C<redo IE<lt>LABELE<gt>>")
+
+=item C<BE<lt>textE<gt>> -- bold text
+X<B> X<< BZ<><> >> X<POD, formatting code, bold> X<bold>
+
+Used for switches ("C<perl's BE<lt>-nE<gt> switch>"), programs
+("C<some systems provide a BE<lt>chfnE<gt> for that>"),
+emphasis ("C<be BE<lt>careful!E<gt>>"), and so on
+("C<and that feature is known as BE<lt>autovivificationE<gt>>").
+
+=item C<CE<lt>codeE<gt>> -- code text
+X<C> X<< CZ<><> >> X<POD, formatting code, code> X<code>
+
+Renders code in a typewriter font, or gives some other indication that
+this represents program text ("C<CE<lt>gmtime($^T)E<gt>>") or some other
+form of computerese ("C<CE<lt>drwxr-xr-xE<gt>>").
+
+=item C<LE<lt>nameE<gt>> -- a hyperlink
+X<L> X<< LZ<><> >> X<POD, formatting code, hyperlink> X<hyperlink>
+
+There are various syntaxes, listed below.  In the syntaxes given,
+C<text>, C<name>, and C<section> cannot contain the characters
+'/' and '|'; and any '<' or '>' should be matched.
+
+=over
+
+=item *
+
+C<LE<lt>nameE<gt>>
+
+Link to a Perl manual page (e.g., C<LE<lt>Net::PingE<gt>>).  Note
+that C<name> should not contain spaces.  This syntax
+is also occasionally used for references to Unix man pages, as in
+C<LE<lt>crontab(5)E<gt>>.
 
 =item *
 
-An ordinary block of text.  It will be filled, and maybe even
-justified.  Certain interior sequences are recognized both
-here and in commands:
+C<LE<lt>name/"sec"E<gt>> or C<LE<lt>name/secE<gt>>
 
-    I<text>     italicize text, used for emphasis or variables
-    B<text>     embolden text, used for switches and programs
-    S<text>     text contains non-breaking spaces
-    C<code>	literal code 
-    L<name>     A link (cross reference) to name
-		    L<name>		manual page
-		    L<name/ident>	item in manual page
-		    L<name/"sec">	section in other manual page
-		    L<"sec">		section in this manual page
-					(the quotes are optional)
-		    L</"sec">		ditto
-    F<file>	Used for filenames
-    X<index>	An index entry
-    ZE<lt>E<gt>	A zero-width character
-    E<escape>   A named character (very similar to HTML escapes)
-		    E<lt>		A literal <
-		    E<gt>		A literal >
-		    (these are optional except in other interior
-		     sequences and when preceded by a capital letter)
-		    E<n>		Character number n (probably in ASCII)
-    	    	    E<html>		Some non-numeric HTML entity, such
-					as E<Agrave>
+Link to a section in other manual page.  E.g.,
+C<LE<lt>perlsyn/"For Loops"E<gt>>
+
+=item *
+
+C<LE<lt>/"sec"E<gt>> or C<LE<lt>/secE<gt>>
+
+Link to a section in this manual page.  E.g.,
+C<LE<lt>/"Object Methods"E<gt>>
+
+=back
+
+A section is started by the named heading or item.  For
+example, C<LE<lt>perlvar/$.E<gt>> or C<LE<lt>perlvar/"$."E<gt>> both
+link to the section started by "C<=item $.>" in perlvar.  And
+C<LE<lt>perlsyn/For LoopsE<gt>> or C<LE<lt>perlsyn/"For Loops"E<gt>>
+both link to the section started by "C<=head2 For Loops>"
+in perlsyn.
+
+To control what text is used for display, you
+use "C<LE<lt>text|...E<gt>>", as in:
+
+=over
+
+=item *
+
+C<LE<lt>text|nameE<gt>>
+
+Link this text to that manual page.  E.g.,
+C<LE<lt>Perl Error Messages|perldiagE<gt>>
+
+=item *
+
+C<LE<lt>text|name/"sec"E<gt>> or C<LE<lt>text|name/secE<gt>>
+
+Link this text to that section in that manual page.  E.g.,
+C<LE<lt>postfix "if"|perlsyn/"Statement Modifiers"E<gt>>
+
+=item *
+
+C<LE<lt>text|/"sec"E<gt>> or C<LE<lt>text|/secE<gt>>
+or C<LE<lt>text|"sec"E<gt>>
+
+Link this text to that section in this manual page.  E.g.,
+C<LE<lt>the various attributes|/"Member Data"E<gt>>
 
 =back
 
-That's it.  The intent is simplicity, not power.  I wanted paragraphs
-to look like paragraphs (block format), so that they stand out
-visually, and so that I could run them through fmt easily to reformat
-them (that's F7 in my version of B<vi>).  I wanted the translator (and not
-me) to worry about whether " or ' is a left quote or a right quote
-within filled text, and I wanted it to leave the quotes alone, dammit, in
-verbatim mode, so I could slurp in a working program, shift it over 4
-spaces, and have it print out, er, verbatim.  And presumably in a
-constant width font.
+Or you can link to a web page:
+
+=over
+
+=item *
+
+C<LE<lt>scheme:...E<gt>>
+
+C<LE<lt>text|scheme:...E<gt>>
+
+Links to an absolute URL.  For example, C<LE<lt>http://www.perl.org/E<gt>> or
+C<LE<lt>The Perl Home Page|http://www.perl.org/E<gt>>.
+
+=back
+
+=item C<EE<lt>escapeE<gt>> -- a character escape
+X<E> X<< EZ<><> >> X<POD, formatting code, escape> X<escape>
+
+Very similar to HTML/XML C<&I<foo>;> "entity references":
+
+=over
+
+=item *
+
+C<EE<lt>ltE<gt>> -- a literal E<lt> (less than)
+
+=item *
+
+C<EE<lt>gtE<gt>> -- a literal E<gt> (greater than)
+
+=item *
+
+C<EE<lt>verbarE<gt>> -- a literal | (I<ver>tical I<bar>)
+
+=item *
+
+C<EE<lt>solE<gt>> = a literal / (I<sol>idus)
+
+The above four are optional except in other formatting codes,
+notably C<LE<lt>...E<gt>>, and when preceded by a
+capital letter.
+
+=item *
+
+C<EE<lt>htmlnameE<gt>>
+
+Some non-numeric HTML entity name, such as C<EE<lt>eacuteE<gt>>,
+meaning the same thing as C<&eacute;> in HTML -- i.e., a lowercase
+e with an acute (/-shaped) accent.
+
+=item *
+
+C<EE<lt>numberE<gt>>
 
-In particular, you can leave things like this verbatim in your text:
+The ASCII/Latin-1/Unicode character with that number.  A
+leading "0x" means that I<number> is hex, as in
+C<EE<lt>0x201EE<gt>>.  A leading "0" means that I<number> is octal,
+as in C<EE<lt>075E<gt>>.  Otherwise I<number> is interpreted as being
+in decimal, as in C<EE<lt>181E<gt>>.
 
-    Perl
-    FILEHANDLE
-    $variable
-    function()
-    manpage(3r)
+Note that older Pod formatters might not recognize octal or
+hex numeric escapes, and that many formatters cannot reliably
+render characters above 255.  (Some formatters may even have
+to use compromised renderings of Latin-1 characters, like
+rendering C<EE<lt>eacuteE<gt>> as just a plain "e".)
 
-Doubtless a few other commands or sequences will need to be added along
-the way, but I've gotten along surprisingly well with just these.
+=back
+
+=item C<FE<lt>filenameE<gt>> -- used for filenames
+X<F> X<< FZ<><> >> X<POD, formatting code, filename> X<filename>
+
+Typically displayed in italics.  Example: "C<FE<lt>.cshrcE<gt>>"
+
+=item C<SE<lt>textE<gt>> -- text contains non-breaking spaces
+X<S> X<< SZ<><> >> X<POD, formatting code, non-breaking space> 
+X<non-breaking space>
+
+This means that the words in I<text> should not be broken
+across lines.  Example: S<C<SE<lt>$x ? $y : $zE<gt>>>.
+
+=item C<XE<lt>topic nameE<gt>> -- an index entry
+X<X> X<< XZ<><> >> X<POD, formatting code, index entry> X<index entry>
+
+This is ignored by most formatters, but some may use it for building
+indexes.  It always renders as empty-string.
+Example: C<XE<lt>absolutizing relative URLsE<gt>>
+
+=item C<ZE<lt>E<gt>> -- a null (zero-effect) formatting code
+X<Z> X<< ZZ<><> >> X<POD, formatting code, null> X<null>
+
+This is rarely used.  It's one way to get around using an
+EE<lt>...E<gt> code sometimes.  For example, instead of
+"C<NEE<lt>ltE<gt>3>" (for "NE<lt>3") you could write
+"C<NZE<lt>E<gt>E<lt>3>" (the "ZE<lt>E<gt>" breaks up the "N" and
+the "E<lt>" so they can't be considered
+the part of a (fictitious) "NE<lt>...E<gt>" code.
+
+=for comment
+ This was formerly explained as a "zero-width character".  But it in
+ most parser models, it parses to nothing at all, as opposed to parsing
+ as if it were a E<zwnj> or E<zwj>, which are REAL zero-width characters.
+ So "width" and "character" are exactly the wrong words.
+
+=back
+
+Most of the time, you will need only a single set of angle brackets to
+delimit the beginning and end of formatting codes.  However,
+sometimes you will want to put a real right angle bracket (a
+greater-than sign, '>') inside of a formatting code.  This is particularly
+common when using a formatting code to provide a different font-type for a
+snippet of code.  As with all things in Perl, there is more than
+one way to do it.  One way is to simply escape the closing bracket
+using an C<E> code:
+
+    C<$a E<lt>=E<gt> $b>
+
+This will produce: "C<$a E<lt>=E<gt> $b>"
+
+A more readable, and perhaps more "plain" way is to use an alternate
+set of delimiters that doesn't require a single ">" to be escaped.
+Doubled angle brackets ("<<" and ">>") may be used I<if and only if there is
+whitespace right after the opening delimiter and whitespace right
+before the closing delimiter!>  For example, the following will
+do the trick:
+X<POD, formatting code, escaping with multiple brackets>
+
+    C<< $a <=> $b >>
+
+In fact, you can use as many repeated angle-brackets as you like so
+long as you have the same number of them in the opening and closing
+delimiters, and make sure that whitespace immediately follows the last
+'<' of the opening delimiter, and immediately precedes the first '>'
+of the closing delimiter.  (The whitespace is ignored.)  So the
+following will also work:
+X<POD, formatting code, escaping with multiple brackets>
+
+    C<<< $a <=> $b >>>
+    C<<<<  $a <=> $b     >>>>
+
+And they all mean exactly the same as this:
+
+    C<$a E<lt>=E<gt> $b>
+
+The multiple-bracket form does not affect the interpretation of the contents of
+the formatting code, only how it must end.  That means that the examples above
+are also exactly the same as this:
+
+    C<< $a E<lt>=E<gt> $b >>
+
+As a further example, this means that if you wanted to put these bits of
+code in C<C> (code) style:
+
+    open(X, ">>thing.dat") || die $!
+    $foo->bar();
+
+you could do it like so:
+
+    C<<< open(X, ">>thing.dat") || die $! >>>
+    C<< $foo->bar(); >>
+
+which is presumably easier to read than the old way:
+
+    C<open(X, "E<gt>E<gt>thing.dat") || die $!>
+    C<$foo-E<gt>bar();>
+
+This is currently supported by pod2text (Pod::Text), pod2man (Pod::Man),
+and any other pod2xxx or Pod::Xxxx translators that use
+Pod::Parser 1.093 or later, or Pod::Tree 1.02 or later.
+
+=head2 The Intent
+X<POD, intent of>
+
+The intent is simplicity of use, not power of expression.  Paragraphs
+look like paragraphs (block format), so that they stand out
+visually, and so that I could run them through C<fmt> easily to reformat
+them (that's F7 in my version of B<vi>, or Esc Q in my version of
+B<emacs>).  I wanted the translator to always leave the C<'> and C<`> and
+C<"> quotes alone, in verbatim mode, so I could slurp in a
+working program, shift it over four spaces, and have it print out, er,
+verbatim.  And presumably in a monospace font.
+
+The Pod format is not necessarily sufficient for writing a book.  Pod
+is just meant to be an idiot-proof common source for nroff, HTML,
+TeX, and other markup languages, as used for online
+documentation.  Translators exist for B<pod2text>, B<pod2html>,
+B<pod2man> (that's for nroff(1) and troff(1)), B<pod2latex>, and
+B<pod2fm>.  Various others are available in CPAN.
+
+
+=head2 Embedding Pods in Perl Modules
+X<POD, embedding>
+
+You can embed Pod documentation in your Perl modules and scripts.
+Start your documentation with an empty line, a "=head1" command at the
+beginning, and end it with a "=cut" command and an empty line.  Perl
+will ignore the Pod text.  See any of the supplied library modules for
+examples.  If you're going to put your Pod at the end of the file, and
+you're using an __END__ or __DATA__ cut mark, make sure to put an
+empty line there before the first Pod command.
+
+  __END__
+
+  =head1 NAME
+
+  Time::Local - efficiently compute time from local and GMT time
+
+Without that empty line before the "=head1", many translators wouldn't
+have recognized the "=head1" as starting a Pod block.
+
+=head2 Hints for Writing Pod
+
+=over
+
+=item *
+X<podchecker> X<POD, validating>
+
+The B<podchecker> command is provided for checking Pod syntax for errors
+and warnings.  For example, it checks for completely blank lines in
+Pod blocks and for unknown commands and formatting codes.  You should
+still also pass your document through one or more translators and proofread
+the result, or print out the result and proofread that.  Some of the
+problems found may be bugs in the translators, which you may or may not
+wish to work around.
+
+=item *
+
+If you're more familiar with writing in HTML than with writing in Pod, you
+can try your hand at writing documentation in simple HTML, and converting
+it to Pod with the experimental L<Pod::HTML2Pod|Pod::HTML2Pod> module,
+(available in CPAN), and looking at the resulting code.  The experimental
+L<Pod::PXML|Pod::PXML> module in CPAN might also be useful.
+
+=item *
 
-Note that I'm not at all claiming this to be sufficient for producing a
-book.  I'm just trying to make an idiot-proof common source for nroff,
-TeX, and other markup languages, as used for online documentation.
-Translators exist for B<pod2man>  (that's for nroff(1) and troff(1)),
-B<pod2html>, B<pod2latex>, and B<pod2fm>.
+Many older Pod translators require the lines before every Pod
+command and after every Pod command (including "=cut"!) to be a blank
+line.  Having something like this:
 
-=head1 Embedding Pods in Perl Modules
+ # - - - - - - - - - - - -
+ =item $firecracker->boom()
 
-You can embed pod documentation in your Perl scripts.  Start your
-documentation with a "=head1" command at the beginning, and end it
-with a "=cut" command.  Perl will ignore the pod text.  See any of the
-supplied library modules for examples.  If you're going to put your
-pods at the end of the file, and you're using an __END__ or __DATA__
-cut mark, make sure to put an empty line there before the first pod
-directive.
+ This noisily detonates the firecracker object.
+ =cut
+ sub boom {
+ ...
 
-    __END__
+...will make such Pod translators completely fail to see the Pod block
+at all.
 
+Instead, have it like this:
 
-    =head1 NAME
+ # - - - - - - - - - - - -
 
-    modern - I am a modern module
+ =item $firecracker->boom()
 
-If you had not had that empty line there, then the translators wouldn't
-have seen it.
+ This noisily detonates the firecracker object.
 
-=head1 Common Pod Pitfalls
+ =cut
 
-=over 4
+ sub boom {
+ ...
 
 =item *
 
-Pod translators usually will require paragraphs to be separated by
-completely empty lines.  If you have an apparently empty line with
-some spaces on it, this can cause odd formatting.
+Some older Pod translators require paragraphs (including command
+paragraphs like "=head2 Functions") to be separated by I<completely>
+empty lines.  If you have an apparently empty line with some spaces
+on it, this might not count as a separator for those translators, and
+that could cause odd formatting.
 
 =item *
 
-Translators will mostly add wording around a LE<lt>E<gt> link, so that
-C<LE<lt>foo(1)E<gt>> becomes "the I<foo>(1) manpage", for example (see
-B<pod2man> for details).  Thus, you shouldn't write things like C<the
-LE<lt>fooE<gt> manpage>, if you want the translated document to read
-sensibly.
+Older translators might add wording around an LE<lt>E<gt> link, so that
+C<LE<lt>Foo::BarE<gt>> may become "the Foo::Bar manpage", for example.
+So you shouldn't write things like C<the LE<lt>fooE<gt>
+documentation>, if you want the translated document to read sensibly.
+Instead, write C<the LE<lt>Foo::Bar|Foo::BarE<gt> documentation> or
+C<LE<lt>the Foo::Bar documentation|Foo::BarE<gt>>, to control how the
+link comes out.
 
 =item *
 
-The script F<pod/checkpods.PL> in the Perl source distribution
-provides skeletal checking for lines that look empty but aren't
-B<only>, but is there as a placeholder until someone writes
-Pod::Checker.  The best way to check your pod is to pass it through
-one or more translators and proofread the result, or print out the
-result and proofread that.  Some of the problems found may be bugs in
-the translators, which you may or may not wish to work around.
+Going past the 70th column in a verbatim block might be ungracefully
+wrapped by some formatters.
 
 =back
 
 =head1 SEE ALSO
 
-L<pod2man> and L<perlsyn/"PODs: Embedded Documentation">
+L<perlpodspec>, L<perlsyn/"PODs: Embedded Documentation">,
+L<perlnewmod>, L<perldoc>, L<pod2html>, L<pod2man>, L<podchecker>.
 
 =head1 AUTHOR
 
-Larry Wall
+Larry Wall, Sean M. Burke
 
+=cut