# Copyright (C) 2005 Joshua Hoblitt
#
# $Id: Tidy.pm,v 1.2 2005/10/09 22:17:18 jhoblitt Exp $
package Test::Pod::Tidy;
use strict;
use Encode;
use Encode::Newlines;
use base qw( Exporter );
use vars qw(
@EXPORT
$MESSY_POD
$TIDY_POD
$VALID_POD
$INVALID_POD
$POD_WS_TAIL
$POD_WS_TRIMMED
);
@EXPORT = qw(
$MESSY_POD
$TIDY_POD
$VALID_POD
$INVALID_POD
$POD_WS_TAIL
$POD_WS_TRIMMED
);
$MESSY_POD = encode( Native =><<END );
=head1 NAME
perlpodspec - Plain Old Documentation: format specification and notes
=head1 DESCRIPTION
This document is detailed notes on the Pod markup language. Most
people will only have to read L<perlpod|perlpod> to know how to write
in Pod, but this document may answer some incidental questions to do
with parsing and rendering Pod.
In this document, "must" / "must not", "should" /
"should not", and "may" have their conventional (cf. RFC 2119)
meanings: "X must do Y" means that if X doesn't do Y, it's against
this specification, and should really be fixed. "X should do Y"
means that it's recommended, but X may fail to do Y, if there's a
good reason. "X may do Y" is merely a note that X can do Y at
will (although it is up to the reader to detect any connotation of
"and I think it would be I<nice> if X did Y" versus "it wouldn't
really I<bother> me if X did Y").
Notably, when I say "the parser should do Y", the
parser may fail to do Y, if the calling application explicitly
requests that the parser I<not> do Y. I often phrase this as
"the parser should, by default, do Y." This doesn't I<require>
the parser to provide an option for turning off whatever
feature Y is (like expanding tabs in verbatim paragraphs), although
it implicates that such an option I<may> be provided.
=cut
END
$TIDY_POD = encode( Native =><<END );
=head1 NAME
perlpodspec - Plain Old Documentation: format specification and notes
=head1 DESCRIPTION
This document is detailed notes on the Pod markup language. Most people will
only have to read L<perlpod|perlpod> to know how to write in Pod, but this
document may answer some incidental questions to do with parsing and rendering
Pod.
In this document, "must" / "must not", "should" / "should not", and "may" have
their conventional (cf. RFC 2119) meanings: "X must do Y" means that if X
doesn't do Y, it's against this specification, and should really be fixed. "X
should do Y" means that it's recommended, but X may fail to do Y, if there's a
good reason. "X may do Y" is merely a note that X can do Y at will (although
it is up to the reader to detect any connotation of "and I think it would be
I<nice> if X did Y" versus "it wouldn't really I<bother> me if X did Y").
Notably, when I say "the parser should do Y", the parser may fail to do Y, if
the calling application explicitly requests that the parser I<not> do Y. I
often phrase this as "the parser should, by default, do Y." This doesn't
I<require> the parser to provide an option for turning off whatever feature Y
is (like expanding tabs in verbatim paragraphs), although it implicates that
such an option I<may> be provided.
=cut
END
$VALID_POD = encode( Native =><<END );
=pod
=head1 foo
bar baz.
=cut
END
$INVALID_POD = encode( Native =><<END );
=pod
=end
=begin
=bogustag
=back
END
$POD_WS_TAIL = encode( Native =><<END );
=head2 C source tests
C source tests are usually located in F<t/src/*.t>. A simple test looks like:
c_output_is(<<'CODE', <<'OUTPUT', "name for test");
#include <stdio.h>
#include "parrot/parrot.h"
#include "parrot/embed.h"
=cut
END
$POD_WS_TRIMMED = encode( Native =><<END );
=head2 C source tests
C source tests are usually located in F<t/src/*.t>. A simple test looks like:
c_output_is(<<'CODE', <<'OUTPUT', "name for test");
#include <stdio.h>
#include "parrot/parrot.h"
#include "parrot/embed.h"
=cut
END
1;
__END__