Bug #51992 for XML-Filter-Essex: (Patch] POD nits

The attached patch fixes some POD, which renders wrong, at least at search.cpan.org.

diff --git a/lib/XML/Essex/Base.pm b/lib/XML/Essex/Base.pm index be49cd1..e83d3ae 100644 --- a/lib/XML/Essex/Base.pm +++ b/lib/XML/Essex/Base.pm @@ -133,7 +133,7 @@ sub import { =item main The main routine. Overload this or pass in a code ref -to C<new( Main => \&foo )> or C<set_main( \&foo )> to set this. +to C<< new( Main => \&foo ) >> or C<set_main( \&foo )> to set this. =cut diff --git a/lib/XML/Essex/Model.pm b/lib/XML/Essex/Model.pm index a1687d8..4d25952 100644 --- a/lib/XML/Essex/Model.pm +++ b/lib/XML/Essex/Model.pm @@ -25,7 +25,7 @@ both the C<isa()> method/function and for class creation. All objects are actually blessed in to classes using the long name, like C<XML::Essex::start_element> even if you use an abbreviation like -C<XML::Essex::start_elt->new> to create them. +C<< XML::Essex::start_elt->new >> to create them. =head2 Stringification @@ -1141,7 +1141,7 @@ of getting at any data in the events) and that upstream filters may send blessed, tied, or overloaded objects to us and they will not be molested unless the Essex filter messes with them. There is also an implementation reason for this, it makes overloading hash accesses -like C<$_->{}> easier to implement. +like C<< $_->{} >> easier to implement. Passing an Essex event to a constructor for a new Essex event does result in a deep copy of the referenced data (via