Aaron Sherman writes: > Larry Wall wrote: > > > $_ $x Type of Match Implied Matching Code > > ====== ===== ===================== ============= > > Any Code<$> scalar sub truth match if $x($_) > > > This bit of POD made me think about POD's lack of tabular formatting,
What? I see a table. What lack? It looks an awful lot more like a table to me than: > <> H< C<$_> | C<$x> | Type of Match Implied | Matching Code > > T< Any | CodeC<< <$> >> | scalar sub truth | match if C<$x($_)> > does. There are many great things about POD, and this is one of them. Okay, so I want a table in my docs. I don't want to read perlpod to figure out how to write a table. I just write my table and it works as long as I indent. Sure, it won't be as pretty when it gets turned into HTML or LaTeX, but the point is, that it's readable when it gets there in any case. The point of documentation isn't to be pretty, it's to be descriptive. Another great thing about POD is that it doesn't let you be pretty unless you're a brilliant ASCII artist. And then you can focus on your content rather than your look. Excuse me, you I<have to> focus on your content rather than your look. I've already had my epiphany about POD, though, so I'll spare doing it again. In short, there are two things that I see about POD that need to change: =over =item 1) C<=directive> lines shouldn't have to be in their own paragraph, in order to condense lists and make them more readable from POD source. =item 2) (The one that has been made clear several times) When an =end foo closes a =begin foo that opened the POD section, the =end should close the POD section. =back No tables. Keep the number of things that I can distract myself with when I should be writing documentation down to a clean 565. I don't need 566. Luke
