Re: The eternal "use XXX instead of POD" debate (was: Project Start: ?Section 1)
[email protected] ("Sean M. Burke")
| Newsgroups | perl.pod-people,perl.perl6.documentation |
|---|---|
| Message-ID | <[email protected]> |
wrote on Mon, 11 Nov 2002 15:50:34 -0800:
>I'd love to see a cleaner POD,
Have you looked at perlpodspec, and had a look at the new Pod::Simple
formatters?
>with tables,
I like tables, but it is sheer agony to produce tables in many output
formats. I'm starting to wonder whether some kind of verbatim block might
be the answer, so that parsers that have said that they know about tables,
will get tables; and otherwise they'll get the verbatim block.
Something like:
#:table-lines
| | |
inches twips points centimeters
20 tw 1 pt
40 tw 2 pt
~57 tw .1cm
60 tw 3 pt
80 tw 4 pt
1/16" 90 tw 4.5 pts
That assumes that each line is one row. Presumably a similar syntax could
be adapted to cases where that's not the case.
That's vaguely like the verbatim-formatted stuff that I've been
experimenting with lately, where the second line here:
flock COUNTER, LOCK_EX;
#: ^^^^^^^
bolds the characters above the "^".
>better support for lists,
In what sense? If you want something to happen in Pod, ask on the
Pod-people list.
>and the ability to turn syntax inferencing on a per-document basis.
On the Pod-people list, we have mostly decided that those inference rules
are more trouble than they are worth, precisely because they are
unpredictable, and typically there's no way to disable them. I am entirely
happy with a future for Pod where no formatter (or, god help us, a parser)
thinks it its duty to turn "an O(N) solution" into "an C<O(N)> solution".
I distinctly sense that the discussion here is very much like previous
grieve-and-growl sessions, where people too often say little more than "I
don't like X about Pod" when they're not talking about Pod at all, but just
some some appalling old version of Pod::Html or Pod::Man. It's like
complaining that Perl doesn't have objects since you never know when you'll
be using Perl 4.
--
Sean M. Burke http://search.cpan.org/author/sburke/